> 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.

It does not matter what kinds of children they make... a collection has a well-typed-usage. When you get an item out of a collection, you have two options:

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

That's fair. I don't know how SML deals with this, but Haskell handles it with type classes and (in your UI example) existential data types.

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{}.