The book expands upon his thesis, and has Haskell source code in an appendix. I'm more familiar with the book than that PDF (and definitely recommend it), but comparing their tables of contents would probably help.
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.
Interesting. The parallels between ML and Scheme, two languages invented in the '70s and in an academic setting, are striking: the core language is great, but the community is divided into ever-so-slightly incompatible implementations, so, in practice, there's very little sharing. Therefore, it's impractical to do most "large" projects in the language, due to lack of critical mass of useful libraries. ML/Scheme end up being learning languages, for the most part, and then everyone moves on to {OCaml, Haskell}/Common Lisp to get real work done.
I would say these similar outcomes are a repudiation of the idea that multiple implementations of the same language is a good thing, but that hasn't hurt C's popularity. More likely, it has something to do with their roots in programming language research. Maybe ML and Scheme are too good for their own good, and other academics can't resist using them as a basis for their own pet ideas. Perhaps a truly successful (read, "widely-adopted") programming language has to be flawed just enough to discourage anyone from trying to improve on it. Worse is better strikes again?
Yeah, I concluded the same thing. Languages with standards seem to be largely worse off than languages with canonical implementations with regard to interoperability and ecosystem coherence. I think maybe the problem is that if your standard isn't restrictive enough to ensure general interoperability, you end up without it.
It seems strange that Haskell seems to be a special case to this, but even there you see language extensions that ghc supports but Hugs et al do not. It's just that, for most people, ghc just wins outright. SML/NJ vs MLton is a harder question to decide given the freakish performance that MLton can achieve.
Thanks for your take. I quite like OCaml---it's syntax is a bit quirky, but I guess I've used it enough that I've mostly stopped seeing the quirks. I've wanted to use Haskell for a larger project for a while now, but the right project hasn't presented itself.
I'm curious what industry you're in that you're able to make significant use of Haskell?
I'm curious what industry you're in that you're able to make significant use of Haskell?
Haha. I'm an integrated circuit designer. When I write Haskell, it's for my side projects or for some kind of optimization or signal processing problem.
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
Thanks for the pointer. My first thought is that I didn't see anything overwhelmingly compelling there, although I can see the benefits of having a "standard" language with many implementations vs. an implementation defined language.
As far as OCaml OO goes, I rarely use it (with one exception: objects implementing the "visitor pattern" for traversing the AST of a C program [1]) so its existence doesn't affect me. Perhaps I'd view the resulting language complexity as a negative if I had to maintain OCaml code that was OO heavy.
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.
