Item — HN Reader

I got really excited reading the 1995 email as an announcement that INRIA was releasing a new SML-based language. The association I can't get out of my head is: SML is to C as OCaml is to C++. This is backed (to some degree) even in this email:

  > ... in 20 years, the language picked up many language
  features that were open research problems in 1995, such as objects and
  classes with type inference, polymorphic variants, first-class polymorphism,
  and first-class modules.

SML is a much simpler language and I think a solid SML kernel with a good (read: modern, web-friendly) standard library targeting LLVM or the JVM could be a real winner for commercial use.

4 comments

> SML is to C as OCaml is to C++

In what way though? The amount of concepts and gotchas you have to understand to be proficient at OCaml is nothing compared to C++ in my opinion. I've used SML as well and didn't find it hugely different from OCaml unlike when I went from C to C++.

I agree. OCaml is really cool in many respects, and I like it a lot—but the only thing SML really needs is a modern Basis library that is applicable to today's standard use-cases.

I use SML for the JonPRL proof assistant, and I couldn't be happier. Some things would be a bit easier in OCaml, but to be honest, I love the fact that my code will continue to work without modification for decades, due to the simple fact that SML is a language frozen in time.

> due to the simple fact that SML is a language frozen in time

Unfreeze it, all the extant MLs fall short in one way or another. A modern SML with none of the syntactic cruft of OCaml; the lazy evaluation of Haskell and its non-existent module system; the nutured nature of F# ... that would be ML joy, maybe Rosenberg's 1ML will make that a reality.

We're in the middle ages of computer science language-wise.

Heck, even use HaMLet to bootstrap it.

Hamlet is a portable SML implementation written in SML.

http://www.mpi-sws.org/~rossberg/hamlet/

(Not unlike SICL, which is a portable Common Lisp for R&D https://github.com/robert-strandh/SICL)

I agree that each ML falls short in some ways--I think SML and OCaml are probably the best programming languages ever made, but there's definitely room for improvement. I dream of the "Next Great ML"; 1ML definitely looks interesting in this regard, though I am a bit skeptical of Rossberg's rhetoric on a number of issues.

I use SML over OCaml mostly for cultural & political reasons; SML has a few areas ripe for improvement (some of which are addressed in OCaml, others not):

1. structure sharing in the Definition is so bad that pretty much all the implementations of "S"ML diverge from it in some way. Each implementation of structure sharing is frustrating in its own way.

2. would be nice to be able to do higher-kinded polymorphism, as in 1ML

3. would be nice to unify polymorphism as a mere mode-of-use of functors, as in 1ML (well, this was not invented in 1ML, as I first saw it in Dreyer/Harper/Chakravarty's "Modular Type Classes": http://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf; it may go back as far as the Harper-Stone type theoretic semantics). Combined with higher-order functors (which I believe are proposed to be added to "Successor ML"), this would give a proper treatment to polymorphism at higher kinds.

4. we need to standardize on a package calculus; the ML Basis system as used in Mlton is pretty nice, as is the simpler system used in SML/NJ's "Compilation Manager".

5. modular type classes (analogous to coq's "canonical structures") should be added in order to alleviate the pain of explicitly instantiating functors, etc. We do NOT want "type class coherence" as in Haskell, which amounts to a piece of global state that essentially outlaws local reasoning. I call it the "Antimodularity Restriction", but the name hasn't caught on, as much as Haskell folks like to berate us over our "value restriction" (which is a non-problem, and very useful--though it would be better to reconstruct it in a less ad-hoc way, via the theory of polarization that comes from Girard, and was further developed in light of effects, refinements and polymorphism by Zeilberger in his dissertation).

6. I'd like to (at least) follow OCaml and add the ability to convert between module signatures & existential types; I'm not sure if I am sold on the 1ML approach, which goes quite a bit further than this, but I need to investigate it more.

7. Refinement types would be nice (but PLEASE---do not fix in advance some awful solver or something for this; contra the popular literature at the moment refinement types have NOTHING at all to do with solvers!).

What is a good SML implementation that creates compact binaries that are easy to deploy? (One of OCaml's strength is the compiler that produces native code binaries that don't depend on tons of runtime libraries or other files.)

Mlton? Or is that just an optimizing compiler?

Or you could do the same thing with Ocaml while just using a subset of its features.

Are you trying to prove the C++ analogy? http://stackoverflow.com/questions/3073642/official-c-langua...

A while back, I had to decide which of SML or Ocaml I'd recommend to people interested. I looked up comparisons hopefully from talented developers. Found this one by Chlipala:

http://adam.chlipala.net/mlcomp/

A C and C++ analogy doesn't make sense unless you really cherry-picking. A better analogy would be Wirth's original Pascal for classrooms vs Borland's Turbo Pascal (or Free Pascal): one is designed to get stuff done with syntax and semantic features that make a lot more sense. You can use Ocaml in a style that gets you much benefits of ML. Even Coq extracts to a minimal Ocaml. Or, you can go Jane St with it developing real-world applications with excellent properties that neither SML nor C++ would have in current state.

Talking like Ocaml is ML's C++ is an insult to them. C++ is garbage built on worse garbage to make the landfill smell less. You'll find plenty of C++ developers admitting they only use it because they have to for whatever reason. You don't see that with Ocaml: good design, tools, and community are driving much growth and happy developers. So, it's more "Ocaml: ML Go's Pro" rather than "C++: Bend Over, Here it Comes Again." ;)

I'd characterize OCaml's tools as a mixture of best-of-breed (Merlin, OPAM) and oh-my-god (build tools, debugger). The language itself, if you avert your eyes from the standard library, is pretty damn good though.

That matches the view others have shared with me. A few of them mentioned that Jane St re-wrote the standard library to try to fix that problem. They also gave it back to the community. Have you tried theirs? If not, take a look at it so you can tell us if you think they've gotten past that weakness.

https://janestreet.github.io/

There are least three competing standard libraries: Jane Street's Core (high-quality but fairly big, also generates large binaries due to OCaml's lack of good dead code elimination support), Batteries (older, developed by the community), and Containers (Simon Cruanes' project, mostly - smaller but very well-designed).

They all have their advantages, the issue is that there is no one true alternative standard library, which makes the life of library writers difficult (especially when you want to use a type in your interface that is only present in one of these libraries).

I see the problem. Wouldn't this happen if SML was industrialized to any degree by different players?

Back to Ocaml, what would your proposal be to deal with this aside from adding dead code elimination for Core? That would be my first strategy because Ocaml needs it anyway.

I think Rossberg's (author of 1ML) comparison[0] might be more appropriate because it doesn't make assumptions about what is better or worse in a language - whereas Chlipala's comparison makes a lot of assumptions. I personally don't think a lot of the assumptions he makes are valid especially when languages that are still "popular" and in-use today (C, Go) have features that he would seem to call "academic" rather than professional.

My point being, it's not that simple. Though I will grant that the libraries and existence(!) of an OCaml community is good reason to select OCaml over SML.

[0] https://www.mpi-sws.org/~rossberg/sml-vs-ocaml.html

That is a more thorough comparison. Makes deciding the victor a bit more difficult at language level except to say that there's more similarities than differences. As you said, libraries and community are main deciding point for me if I have to recommend a ML.

However, I do like that ML has a certifying compiler (FLINT). Love to see one for Ocaml for use in critical tools. The Esterel SCADE code generator, done in Ocaml, was manually verified to object code. That and FLINT make me hope it can be done with reasonable effort with Ocaml.

As someone who writes fairly SML-ish OCaml, there definitely are benefits to using OCaml (even if only for the library and tool support... opam really is pretty awesome) over SML. I rarely end up even using the object system and other features that SML lacks, but I find the syntax a bit nicer to read and write. And unlike C++, the standard library doesn't force all the bloat you don't want to deal with on to you, so it's no big deal to write code in SML style.

There is a small difference though: Using those various OCaml features is not going to instantly kill you.

With the deprecated features of C++, I'm not so sure.

Well, of course. The whole of ocaml is still a smaller language than anybody's recommended 20% subset of C++.

Way more power/features with the detailed description of those + library + tools + more = 588 pages. C++ programming language 3rd edition is 1,000+ pages. So, not quite that ratio but clearly one has better signal-to-noise ratio and design than the other. ;)

i upvoted on the theory that that was deliberate :) the internet needs more understated hunour

Sorry to disappoint. Agree the Internet needs more of that. Makes it funnier when people don't get it, start a tangent, and get called on it in an epic way haha.