I used SML as part of the Programming Languages course taught by University of Washington. It's easily one of my favorite languages and I wish there was more library support for it.
I feel the same way. Maybe we can be the change in the world we want to see. There's also OCaml which seems to have more libraries, a single compiler (yay). The downside is OCaml has a ton of features whereas I find SML to be small enough to hold in my head.
On the other hand, you don't need to know all of OCaml to be effective and unknown features are not going to come and bite you while you don't use them.
Most people don't know the object system. Most advanced features are rarely used and kept well hidden in libraries internals (first class modules, extensible types, ...)
You will need to understand functors for some libraries, though, but I would guess that it's true for SML as well. :)
While that's somewhat true, OCaml is still a somewhat "small" language when compared to lots of other functional languages (Haskell, Scala, and even F# to an extent). At the very least, it has an agreed upon subset of the language to use in everyday code (which most languages of similar size or larger lack), which makes almost any code you find on GitHub or wherever perfectly readable.
On the other hand, the standard libraries (or lack thereof, considering there's no wholly agreed upon standard library to use) can feel at times vast and complex since every standard library alternative has its own subtleties that can make it difficult to go back and forth between all these alternatives.
I noticed recently that there's an open PR for Homebrew to add a formula for MLTon. There are still a few glitches to be ironed out, but I'm really hopeful that they can resolve them. I've been using SML/NJ locally for schoolwork, but it'd be really nice to have an easy-to-install, full-fledged SML compiler with top-notch performance installable with just
That would be nice! It would certainly help grow the language even if only for the learning experience. A good install story can only help.
Getting the MLton compiler to install on OS X was pretty straight forward but I've never been able to get Basis to load properly.
I also recently burned an afternoon trying to install MLKit on OS X. This one seemed promising for its good docs, smltojs, and good FFI so I was bummed I couldn't get it work.
SMLNJ installs pretty easily but holy cow do you have to murder your PATH.
Eventually I settled for MoscowML which is a VM rather than native code but it has provided me the best ML on OS X experience so far. I also enjoy having the REPL.
Doesn't build yet but it's great this didn't get lost like other code. It's a shame licensing and ip management keeps some of our works under lock. Imagine books and scientific papers being kept in vaults. It's another good reason to start projects in the open without giving up ownership to a company or some organization. The FSF or INRIA could pull an Oracle and branch off into a closed code base, but that of course won't happen. Just illustrating the dangers of giving copyright ownership to a single entity like FSF or Google for that matter. Sorry for the rant, but INRIA's CLA rubs me the wrong way because they license OCaml as LGPL with the option to relicense under a liberal license exclusively to Caml Consortium members it seems: https://www.reddit.com/r/ocaml/comments/46fiox/ocaml_compile... They are in the right to do so and have valid reasons but it's not a great idea for a project with not that many external contributors.
Alice ML works on Mac OS X as well, although there was a build issue with "Resource temporary unavailable" that I had to work around. Build instructions are in the README: https://github.com/aliceml/aliceml
I hadn't noticed the original page had gone down. It was up a few days ago so hopefully it's only a temporary thing.
I've used Alice ML on a couple of projects for a while and didn't want to see it die so I got permission from the original authors to host a mirror on github and keep the bitrot away. I forked from work that Gareth Smith did on bitbucket a few years back (with his permission) that fixed some issues and added features. I'm the only one working on it at the moment but hopefully others join in. It's survived this long!
We are implementing the Red JonPRL proof assistant (https://github.com/JonPRL/sml-red-jonprl) in SML (using MLton for builds and SML/NJ for development), and could hardly be happier.
Dealing with unicode is a pain, but so far, we've been able to do what we need.
I've always wondered why SML, a language with a proper spec and multiple independent implementations and more coherent design, was overshadowed by OCaml. Maybe it's the spread of developers across different implementations.
Been reading some SML while going through Okasaki's famous classic book.
> I've always wondered why SML, a language with a proper spec and multiple independent implementations and more coherent design, was overshadowed by OCaml.
IMO it's not much of a mystery. For ~15 years "object oriented" was the biggest buzz word in computer science and OCaml was object oriented, while SML was not. At least in the objects, inheritance, and polymorphic way people wanted.
Back when I was in the university, our languages group department was very found of Caml Light, and used it for quite a few classes related to programming languages and compiler design.
There's also Isabelle where TU Munich played a large role together with institutions from other continents and still does.
Also look at http://www.elsman.com/mlkit/ which incorporates many modern features, some of which can be found in similar form in Rust, recalling that the idea for regions wasn't invented by and is older than Rust.
There you'll find more Danish SML folks and links to SMLtoJs and somewhere down a link to the Smackage SML package manager and smbt Smackage build tool.
SML doesn't appear to be as dead as it seems from the outside.
