Standard ML is almost the perfect language—functional-first without all the heavyweight and seemingly endlessly proliferating categorical abstractions which keeps the level of knowledege one needs to be productive low. Plus it’s easy to drop into old school imperative code when needed.
The only thing holdong sml back in my eyes is somewhat clunky syntax and the module system—which is great at first but quickly becomes tricky once you start having to use functors.
A modern, reimagined sml that keeps its core while adopting some of the nicer syntactic improvements from other langs in the family and improving the module system would be a god send
The module syntax is certainly clumsy in comparison to the rest of the language, and it's not just the syntax - everything about functor arguments is a bit murky.
Thanks for the link, it looks just like what I was after!
I've been reading through the paper and it looks really nice. It seems to rely on dependent records, which I assumed might be the case; but it claims the dependency is "benign" and elaborates-way when translated to System-F (I haven't reached that part yet); so it does seem to have found the right "trick" (i.e. a tractable subset of dependent types which enables modules, without losing too much inference or devolving into a game of prove-the-lemma).
Incidentally, it's also a nice use of "first class types" which isn't (fully) dependently-typed. It irks me when I read blog posts about e.g. Agda or Idris, which describe first-class types (i.e. no stratification, passing types in and out of functions, etc.) but call that "dependent types"; then don't mention the actual "dependent" part (type signatures which bind values to names, which can be referenced "later on" in the type).
MLs are good at representing and manipulating complicated data with intricate invariants (e.g. using algebraic data types for representions, pattern-matching for traversing/manipulating data, abstract/existential types for encapsulation and enforcing interfaces, etc.). In practice this makes it good for handling other languages (after all, "ML" stands for "meta language").
Its original purpose was manipulating mathematical proofs/expressions, and it's still popular for that, e.g. Isabelle's core is written in PolyML, Coq is written in Ocaml, and I think some others like the various HOLs use it too; note that these see a little use in industry for verification (although some famous verification examples, like AMD's FPU verification, used ACL2 which is based on Lisp rather than ML).
It's also good for manipulating Web languages like HTML and Javascript, which has spawned a few compile-to-Web languages which are ML-like or implemented in ML, e.g. http://opalang.org and http://www.impredicative.com/ur . This might also be why Facebook made/use Reason ( https://reasonml.github.io ), which AFAIK is an alternative syntax for Ocaml.
Jane Street seem to be heavy users of Ocaml, since they sponsor a lot of work on the compiler and infrastructure.
The wiki page for SML claims it's used by chip manufacturers like ARM, but no citation.
However, languages like Ocaml and F# are direct descendants of ML, and those languages see wider modern adoption. In this sense ML is kind of equivalent to C, and something like Ocaml is kind of equivalent to C++. Haskell is also in the ML family but its laziness and emphasis on purity keeps it a bit separate from its cousins.
In general, FP sees adoption where correctness is of overriding importance -- e.g., Jane Street's use of Ocaml.
ML is a general-purpose programming language, and as such its use case cannot be narrowly specified. (They say it's good for writing compilers, but I wouldn't latch on that.)
OCaml has first-class modules & functors (functions on modules). I can write something like:
let f (type t) some_arg (module M : Stringable with type t = t) = M.to_string some_arg
This will have the type signature
val f : 'a -> (module Stringable with type t = 'a) -> string
In this case the module type Stringable looks like:
module type Stringable = sig
type t
val to_string : t -> string
Functors are just module types so can be used in the same way. Module types fit in as normal values, you don't have to pattern match on them. This works:
Scala is interesting in this sense; I'd consider it to be an ML-like language. It attempts to unify object systems and module systems, and they are fairly first class in Scala. Modules (objects) can be used as normal values; you can encode functors as functions or classes as needed; signatures (traits) are usable as values to some degree, too.
>Furthermore, path-dependent types allow Scala to unify modules and objects, so that the same language constructs can be used to specify the overall structure of a program as well as its implementation details. The unification of the module and term languages is witnessed by the following comparison with the ML module system: Scala objects correspond to ML modules, classes to functors, and interfaces to signatures [Odersky and Zenger 2005].
Otherwise, I love SML syntax, and would be curious to see the answer to this, too. I find it refreshingly simple and consistent. Is it that it uses 'let ... in ... end' and such rather than whitespace or brackets?
Compared to OCaml, SML pattern matching syntax can be frustrating, mainly because there's no guards. It's not needed that often - but when it's needed, the code with guards is much simpler than multiple branches with nested conditionals.
If you like SML, it might be worth trying Erlang. It comes out of a telecom company, too. The mechanical sympathy I love in SML, I find in Erlang. The ideas that seeded SML, seem to have have found more fertile ground at Ericsson where they still thrive. YMMV.
Erlang has dynamic typing, no? Static typing is especially what interests me in SML, and it's a such core thing, I'm kinda honestly confused what's similar between SML and Erlang?? (I don't know either of them well, so I'd be really interested to learn about some deep similarities from experienced people.)
Both languages were designed with a similar audience in mind. Engineers who write programs incidental to engineering in another discipline. Telcom engineers in both cases.
Erlang supports gradual typing with type specs and dialyzer. It's not as strong of a type system as ML, but it's pretty handy and not particularly cumbersome.
> The only thing holdong sml back in my eyes is somewhat clunky syntax and the module system
Those are both tricky, but I think the much bigger deal is that the package ecosystem is about as lush as the parts of Antarctica that are above sea level.
I suspect that the standard getting whacked together before the language really had a chance to mature had the unfortunate effect of stunting its growth.
The only thing holdong sml back in my eyes is somewhat clunky syntax and the module system—which is great at first but quickly becomes tricky once you start having to use functors.
A modern, reimagined sml that keeps its core while adopting some of the nicer syntactic improvements from other langs in the family and improving the module system would be a god send