4 ms·

I always find this simplicity argument weak: SML is a simple language, simpler than Go (at least, in my opinion) and yet is more powerful with its Hindley-Milne

I always find this simplicity argument weak: SML is a simple language, simpler than Go (at least, in my opinion) and yet is more powerful with its Hindley-Milner type system and module system.

tomp 12y ago
"Power" is relative; it's very hard to put values with different types (where the set of types is not known in advance) into a list with SML, except by manually re-implementing the equivalent of Go's interfaces.
- wyager 12y ago
  > it's very hard to put values with different types (where the set of types is not known in advance) into a list with SML 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.
  - tomp 12y ago
    > 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.
    - wyager 12y ago
      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{}.
    - kazagistar 12y ago
      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?
- jlouis 12y ago
  It is very easy to solve. Two solutions: * 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/het-container.fun 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.

I always find this simplicity argument weak: SML is a simple language, simpler than Go (at least, in my opinion) and yet is more powerful with its Hindley-Milner type system and module system.

tomp 12y ago

"Power" is relative; it's very hard to put values with different types (where the set of types is not known in advance) into a list with SML, except by manually re-implementing the equivalent of Go's interfaces.

wyager 12y ago
> it's very hard to put values with different types (where the set of types is not known in advance) into a list with SML 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.
- tomp 12y ago
  > 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.
  - wyager 12y ago
    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{}.
  - kazagistar 12y ago
    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?
jlouis 12y ago
It is very easy to solve. Two solutions: * 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/het-container.fun 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.