union errors

[gelisam]

@osa1 wrote a spec for a variant of union types which is only concerned about errors. I wonder how much of that spec can be implemented as a #lang in Klister?

We can definitely do f1 to f4 using the same technique as for implicit conversion. Although, like in that example, type equality needs to be implemented using a big type-case expression listing all the known types, not ideal.

Klister's type inference can do just f5 easily if it doesn't have to also support f1 through f4. Unfortunately, the implicit conversion technique overrides #%app with a variant which examples the types, and that breaks type inference because #%app expects the types to be known before type inference completes. Still, with an explicit type annotation, it might be possible to match on the rigid type variable instead of the flexible type variable?

f6 (row polymorphism) does not sound possible at all, but it looks like a nice motivating example. Currently, we are intentionally not adding type classes to Klister, instead we are using type classes as a motivating example to let us know which features we could add to Klister in order to make it possible for the user to implement type classes themselves. Similarly, we could use row polymorphism as a motivating example to let us know which features we could add to Klister in order to make it possible for the user to implement row polymorphism themselves.

f7 through f10 look easier than f5, because the list of errors is finite, it's not polymorphic.