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
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
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... (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