The members of the research group I work in are pretty heavy users of OCaml and I'm a big proponent of languages of the ML style. I generally have the impression that OCaml has become the de facto ML implementation. Can anyone make a case why I might want to consider using SML rather than OCaml?
A few years ago, I had some time off from work and decided to spend the week learning *ML. I spent a bunch of time with Standard ML, including the entirety of the older version of the Harper book, and implemented a bunch of nontrivial toys in it.
In the end, after having covered the whole book, I became frustrated with the language and jumped ship (to Haskell with a quick stopover at OCaml). My main reason was fragmentation: SML/NJ, MLton, etc. all have somewhat different "standard" libraries, which means that in many cases you can't use libraries written for one compiler with another. I ended up having to choose which compiler and set of libraries I wanted per project in order to optimize the availability of libraries for that particular project, which is a frustrating experience. I'd rather learn the idiosyncrasies of one compiler than two.
Before jumping to Haskell, I dabbled in OCaml. I did not implement anything serious with it; rather, I went back and reimplemented a couple of the small toys I'd done in SML using OCaml. I decided that if I had to choose between one of these and the other, I'd probably end up going with OCaml: since there's only one major implementation, you won't run into the frustrating experience of trying to merge two disjoint but frustratingly similar ecosystems. To my sensibilities, however, OCaml is a bit uglier syntactically than SML. In the end, I just never clicked with OCaml, and decided that Haskell would scratch my itch better (and it has).
Having said all that, I don't mean this to imply that you shouldn't read this book! Reading Harper's book on SML made it much easier to pick up OCaml and Haskell, and I definitely consider it an excellent use of my time. SML is a really nice language and a good introduction to Hindley-Milner, but the SML ecosystem is something of a jungle and you'll probably get frustrated if you stay too long. The biggest thing going for SML vs OCaml, in my opinion, is that the syntax is just plain nicer.
I have basically switched to SML from OCaml over the past year, and to be honest there aren't huge differences between the languages.
Objects, classes, polymorphic variants, and labels are all missing from SML, but none of them are a big deal. SML has slightly nicer records, in that you don't need to declare a record type, and can (and often are) used in a way similar to labeled arguments in OCaml. Unfortunately, structures cannot contain functors, and functors cannot return functors. Since I switched, first class modules have been added to OCaml, but I never used them in OCaml so I don't know how useful they would be.
One benefit of SML I have found is that function applications (including operator applications) are clearly separated from other types of expressions in the precedence parsing, so it is easier to remember the precedence rules in SML than it is in OCaml.
So, all of that is less than compelling, but I mention it because if you are comfortable with OCaml, you will likely be comfortable with SML. The reason I switched is because of MLton, which is pretty outstanding at optimization. You can write in whichever style works for you, because all the stylistic changes you would use with other compilers or interpreters for performance reasons don't really have any effect. There is basically no runtime barrier for using any kind of abstraction. This doesn't tend to show in the types of microbenchmarks that people often use for comparing languages (for simple programs, OCaml and MLton have pretty similar performance), but it's very nice for larger programs.
Since Standard ML doesn't directly support OO, I imagine the language is simpler. Some high-level comparisons on the MLton website: http://mlton.org/OCaml
What is the point of ML now that we have Haskell? This is not meant to be a troll; I'm seriously asking. Haskell proponents mention ML and Miranda only in passing and as lesser (in terms of purity and ease of use) antecedents of Haskell. What reasons are there to still use it?
Just because Haskell is purer that doesn't mean ML is pointless. Under the right circumstances even a functional program can benefit from mutable state. One example (perhaps the only real example; I don't know) can be found in the SML New Jersey implemetation of splay trees, which modifies the tree during certain operations.
Even without the purity question there are other things to consider. ML is evaluated strictly, for example. I don't know much Haskell but I don't believe it has any direct counterpart to ML's functors, either. There are probably many other differences. Haskell is definitely more popular and is still a niche language, so the reason you don't hear much about ML's benefits is probably just because it has so few users.
"...we are placing a strong emphasis on verification and proof as tools for the practicing programmer, chief among these being the infamous hellhounds of Computer Science, induction and recursion."
andrejbauer wants to know why Prof Harper is using SML instead of Haskell. There is a slight technical difficulty about proofs in a lazy language but "Well, in Haskell you’d have to use coinduction rather than induction, since the recursive definitions of datatypes are understood as final coalgebras."
That seems to make the point that ML is easier due to synergies with learning to create inductive proofs in maths lessons.
While I think Haskell is a superior language is most respects and I would definitely prefer it for my personal use, I think SML is probably a better language for teaching, particularly for a language-theory course.
Two are two particular issues: laziness and the type system. Laziness is both complicated in practice and makes reasoning about the evaluation semantics more challenging. It can also lead to unexpected behavior for those unaccustomed to it (which will be nearly everybody). Furthermore, the type system is much more complex which makes it a bad model for learning about implicit typing and type inference.
Because of the purity and laziness in Haskell, it is difficult to reason about the performance of what you're writing in Haskell. Fundamentally, a computer is not functional - it does everything via side effect - and I think Haskell goes too far in abstracting this away.
Let me first say that Haskell is extremely cool and every developer should experiment with it. Laziness supports beautiful/declarative expression of programs, and there are some useful ways of structuring programs (e.g., operating over lazy lists) that are far more natural in Haskell than OCaml.
However, for some programs, having a type-system that is fussy about side-effects imposes a significant effort burden for a meager correctness payoff. (For other programs, this bean counting is a huge win.) Also, I find it tricky to reason about the performance of lazy programs.
OCaml (and presumably SML) hit a practical sweet-spot in the statically-typed functional programming world.
[+] [-] swannodette|15 years ago|reply
[+] [-] pumpmylemma|15 years ago|reply
[+] [-] brooksbp|15 years ago|reply
[+] [-] chwahoo|15 years ago|reply
[+] [-] kwantam|15 years ago|reply
In the end, after having covered the whole book, I became frustrated with the language and jumped ship (to Haskell with a quick stopover at OCaml). My main reason was fragmentation: SML/NJ, MLton, etc. all have somewhat different "standard" libraries, which means that in many cases you can't use libraries written for one compiler with another. I ended up having to choose which compiler and set of libraries I wanted per project in order to optimize the availability of libraries for that particular project, which is a frustrating experience. I'd rather learn the idiosyncrasies of one compiler than two.
Before jumping to Haskell, I dabbled in OCaml. I did not implement anything serious with it; rather, I went back and reimplemented a couple of the small toys I'd done in SML using OCaml. I decided that if I had to choose between one of these and the other, I'd probably end up going with OCaml: since there's only one major implementation, you won't run into the frustrating experience of trying to merge two disjoint but frustratingly similar ecosystems. To my sensibilities, however, OCaml is a bit uglier syntactically than SML. In the end, I just never clicked with OCaml, and decided that Haskell would scratch my itch better (and it has).
Having said all that, I don't mean this to imply that you shouldn't read this book! Reading Harper's book on SML made it much easier to pick up OCaml and Haskell, and I definitely consider it an excellent use of my time. SML is a really nice language and a good introduction to Hindley-Milner, but the SML ecosystem is something of a jungle and you'll probably get frustrated if you stay too long. The biggest thing going for SML vs OCaml, in my opinion, is that the syntax is just plain nicer.
[+] [-] tsuyoshi|15 years ago|reply
Objects, classes, polymorphic variants, and labels are all missing from SML, but none of them are a big deal. SML has slightly nicer records, in that you don't need to declare a record type, and can (and often are) used in a way similar to labeled arguments in OCaml. Unfortunately, structures cannot contain functors, and functors cannot return functors. Since I switched, first class modules have been added to OCaml, but I never used them in OCaml so I don't know how useful they would be.
One benefit of SML I have found is that function applications (including operator applications) are clearly separated from other types of expressions in the precedence parsing, so it is easier to remember the precedence rules in SML than it is in OCaml.
So, all of that is less than compelling, but I mention it because if you are comfortable with OCaml, you will likely be comfortable with SML. The reason I switched is because of MLton, which is pretty outstanding at optimization. You can write in whichever style works for you, because all the stylistic changes you would use with other compilers or interpreters for performance reasons don't really have any effect. There is basically no runtime barrier for using any kind of abstraction. This doesn't tend to show in the types of microbenchmarks that people often use for comparing languages (for simple programs, OCaml and MLton have pretty similar performance), but it's very nice for larger programs.
[+] [-] swannodette|15 years ago|reply
EDIT: Matt Might's summary on SML and OCaml is also quite good http://matt.might.net/articles/best-programming-languages/
[+] [-] redo2|15 years ago|reply
[+] [-] oct|15 years ago|reply
Even without the purity question there are other things to consider. ML is evaluated strictly, for example. I don't know much Haskell but I don't believe it has any direct counterpart to ML's functors, either. There are probably many other differences. Haskell is definitely more popular and is still a niche language, so the reason you don't hear much about ML's benefits is probably just because it has so few users.
[+] [-] alan-crowe|15 years ago|reply
"...we are placing a strong emphasis on verification and proof as tools for the practicing programmer, chief among these being the infamous hellhounds of Computer Science, induction and recursion."
andrejbauer wants to know why Prof Harper is using SML instead of Haskell. There is a slight technical difficulty about proofs in a lazy language but "Well, in Haskell you’d have to use coinduction rather than induction, since the recursive definitions of datatypes are understood as final coalgebras."
That seems to make the point that ML is easier due to synergies with learning to create inductive proofs in maths lessons.
[+] [-] necubi|15 years ago|reply
Two are two particular issues: laziness and the type system. Laziness is both complicated in practice and makes reasoning about the evaluation semantics more challenging. It can also lead to unexpected behavior for those unaccustomed to it (which will be nearly everybody). Furthermore, the type system is much more complex which makes it a bad model for learning about implicit typing and type inference.
[+] [-] tsuyoshi|15 years ago|reply
[+] [-] chwahoo|15 years ago|reply
However, for some programs, having a type-system that is fussy about side-effects imposes a significant effort burden for a meager correctness payoff. (For other programs, this bean counting is a huge win.) Also, I find it tricky to reason about the performance of lazy programs.
OCaml (and presumably SML) hit a practical sweet-spot in the statically-typed functional programming world.