SML vs Ocaml for ECMA script spec.

Daniel C. Wang danwang74 at gmail.com
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
  http://www.ps.uni-sb.de/hamlet/ (A SML definitional interpreter for 
SML in SML)
 3. The language is more well documented and understood then OCaml
    A book search for "Standard ML" on Amazon.com 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:

   http://www.smlnj.org/  (supports call/cc) (the grand daddy of all the 
SML compilers...)
   http://mlton.org/ (supports call/cc, whole program) Supper aggressive 
whole program optimizer.
   http://www.cl.cam.ac.uk/research/tsg/SMLNET/ 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
   http://www.diku.dk/topps/activities/sml-mix.html
   http://www.informatik.uni-freiburg.de/proglang/research/software/mlope/
   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
   http://www.ps.uni-sb.de/~rossberg/SMLvsOcaml.html
-------------------------------------------------------------------------------------------
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) 
(http://www.cs.cmu.edu/~fox/foxnet.html)

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... (http://www.cs.princeton.edu/~danwang/) 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..)
   (http://www.microsoft.com/Windows/CSE/pa/pa_home.mspx) (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