SML vs Ocaml for ECMA script spec.

Daniel C. Wang danwang74 at
Sat Oct 21 09:53:50 PDT 2006

I'm coming late to the thread. However, as a pragmatic decision. Using 
Standard ML is the much better choice, by far.  This is no slur on 
Ocaml. I'd just think for this particular application it is a complete 
no brainier to use SML.Here are the reasons ordered by what I consider 
important for this specification:

 1. There is actually a formal spec for it, that's been published. 
(call/cc is not part of that spec... but that's another issue.)
 2. SML has actually be used to define itself (A SML definitional interpreter for 
 3. The language is more well documented and understood then OCaml
    A book search for "Standard ML" on comes up with 632 hits.
    A book search for  "OCaml" has 154 hits.
    If you compare the first page of hits, any reasonable person can 
conclude SML is a more well documented language.
   You'll see the Standard ML hits are all reference and standards docs 
while the OCaml hits quickly turn into books about Linux...

 4.  Support for call/cc in  SML systems is much better any OCaml 
implementation of call/cc I've ever used.
    The cost of call/cc in SML/NJ is basically an O(1) operation too. 
MLton comes pretty close in practice too.
   The one or two times I've used OCaml, I can get it to reliably stack 
overflow and crash my program.   .

 5. SML compiler technology is far superior to OCaml in terms of the 
high-level optimizations that matter for an executable spec.
   If you want to use the spec as a test oracle:  (supports call/cc) (the grand daddy of all the 
SML compilers...) (supports call/cc, whole program) Supper aggressive 
whole program optimizer. SML.NET translator with 
Visual Studio integration.
   Two of the compilers above are whole-program optimizers, which means 
you'll probably get very good performance
   even for a highly-abstract interpreter. (OCaml  doesn't have a 
whole-program optimizer)
   Throw in the partial-evaluators for SML
   and you can get even better performance and a compiler for free. :)
 6. They really aren't that different, and if you're not using objects 
you might as well just use SML
Some background about me... (i.e. full disclosure as to why I'm an SML 
bigot). As a CMU undergraduate I started working on the Fox Project's 
TCP/IP networking stack (written in SML) 

Afterwards I spent 5 years hard time in a Phd Program at Princeton 
working with Andrew Appel and generally hanging around with the SML/NJ 
crew... ( My thesis was built 
using the MLton backend.

After a detour into networks and  proof hacking. I'm now an MS employee 
at MS.   (Ignore the gmail..address..)
   ( (hacking in 
C++ and COM...ickk..)

> I should add, more constructively, that we are not using the  
> Objective part of OCaml; in fact we are trying to use a subset that  
> will be easy for SML folks to read and write.  But we need the call/ 
> cc patch to OCaml, because we do not want to model an ES4 stack  
> machine or continuation machine.  We want the meta-language to  
> support call/cc directly.
> This is a pragmatic decision, and there are other ways to skin the  
> cat for sure, but they tend to taint the entire reference  
> implementation and make it obscure.  We believe we can keep this call/ 
> cc monster in a box, so that it does not taint the spec and break  
> abstraction everywhere.  It is needed only for yield and perhaps a  
> few other hard cases.


More information about the Es4-discuss mailing list