* Implement open types for the language. OCaml did this in 4.02, and it is very useful. * Heterogenous containers: https://github.com/MLton/mlton/blob/master/lib/mlton/basic/h...
It has its uses, albeit it is rare such a use comes into play.
Probably because that's a terrible thing to do.
If you want to keep a collection of things of different types, you should wrap them in a container type using ADTs.
You can't; as I've said, the set of types is not known in advance. For example, you're building a GUI framework, where a widget has a list of children; you don't know what kinds of children the users of your library will make!
The only way to solve this in a HM system is using closures (existential types), i.e. instead of adding a widget to the list of children, you can add it's .draw() method. This gets complicated the more method you need; you'll end up with a record of methods, i.e. an interface.
(1) You inspect its type with reflection, and make a choice of what to do accordingly. This requires tagging the type at runtime, and is ugly no matter what.
(2) You will use the intersection of features provided by all the types. In other words, some interface representing what each object in the collection can do.
Either way is pretty straightforward to represent. In haskell, the first is a Dynamic type, and the second is a record containing the interface functions. I am pretty sure any other case is a runtime error, unless I missed something?
You don't know everything about the children's types, but you know enough to constrain them into being type safe.
People sometimes do this safely in Go, but all too often they use interface{}.