Polymorphic variants

[michallepicki]

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

[gfngfn]

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:

• Pros:
  • They have extensibility especially useful for representing errors.
• Cons:
  • They tend to complicate type error messages.

(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:

• Benedict R. Gaster and Mark P. Jones. A polymorphic type system for extensible records and variants, 1996.

The row-based records introduced by #39 is based on this theory.