Just want to push back a bit and leave a dissenting view on ML for the Working Programmer. If one actually works their way through the text, by the end they will have written a basic interpreter for the lambda calculus, and a small tactics oriented theorem prover, either one of which is highly illuminating to someone who hasn't done this before. The text may not educate a reader on dependent type theory or similar developments but I'm struggling to understand how it is otherwise "dated". Other than that thank you for keeping SML in front of people, I for one appreciate it, its probably my favorite language these days

I see your point. I guess it's just the title that has turned me off even after reading the book.

It doesn't seem to send the right message these days if the idea is that working programmers are building lambda calculus interpreters or theorem provers? Even interpreting a lisp would seem more practical.

I think Practical Common Lisp was more in the right track for content but today I'd focus more explicitly on language design or backend system design.

Andrew Appel's book does already fill the language design slot though nicely.

2. Good to know. I needed to do a "sudo apt install libpolyml-dev", because otherwise it wouldn't link.

3. Thanks for the tip! That will save me a world of pain.

I absolutely love ML for the Working Programmer, but I think you have to see it as a philosophical text as much as a tutorial.

To these points, I'd say

1. I find Emacs sml-mode is just about up to it. I do have complaints - I wish it would pull back the indentation more in lines that continue an expression, it doesn't handle multiple "where" clauses elegantly, it misaligns anonymous function alternatives - but every time I consider trying to fix them I decide they don't quite upset me enough. It's a slight pity though because I strongly believe a language should be auto-indentable (life's too short to indent code yourself), and SML is, just not quite with the existing mode.

2. I like to use Poly/ML for automatic builds during development and MLton for "production" builds - both producing executables. There are still problems on Windows, which doesn't have a properly native MLton port - the existing one uses MinGW which is ok-ish but not what I would prefer. (MLton has a code generator that produces C, so the limitation is that the runtime hasn't been ported rather than with the compiler itself.)

3. Agree, "rlwrap poly"

4. I like inline type decorations, but I also like to omit them most of the time. I think you do get some feel for when it's a good idea to add them, to clarify things for the call site or check your own intuition about the deduced types. Module boundaries (with signatures) also form a natural firebreak for out-of-control type errors.

> 2. I like to use Poly/ML for automatic builds during development and MLton for "production" builds

Do you have/use any dependencies? Like a http/2 (or tls capable) web server, a database client or a gui library? If you do, how does that work with two implementations - if not... What kind of programs do you write/problems are you solving?

Re (2): SML/NJ has a similar scheme to dump a heap image to get an executable.