-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Polymorphic variants #54
Comments
Although they may well be worth supporting in the future, I don’t have a plan to introduce polymorphic variants now. As you note, polymorphic variants have the following pros/cons compared to (ordinary) variants:
(As to some compiler targets, using polymorphic variants degrade performance. As long as compiling to Erlang, however, probably it does not matter; they can be represented by atoms and tuples as ordinary variants are in the Sesterl compiler.) In my experience so far, in many cases, error handling can be achieved by using ordinary variants and data abstraction. This may be partly because in Erlang errors are likely to be uniformly handled as anomalies, not as values that should be used for recovery. Thus I’m not so keen on supporting polymorphic variants currently. If we decide to introduce polymorphic variants in the future, the following row-based theory can probably be used for reference:
The row-based records introduced by #39 is based on this theory. |
Are polymorphic variants planned? They are quite useful for error handling. I understand they complicate type checking, and can lead to degraded performance and poor error messages
The text was updated successfully, but these errors were encountered: