SML vs Ocaml for ECMA script spec.

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

SML vs Ocaml for ECMA script spec.

Daniel C. Wang-2
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.

*

Reply | Threaded
Open this post in threaded view
|

Re: SML vs Ocaml for ECMA script spec.

Daniel C. Wang-2
Also some tidbits from..
  http://www.ffconsultancy.com/free/ray_tracer/languages.html
who did an independent comparison of a ray-trace benchmark. I've snipped
the bits I think are relevant to the discussion. This is the most
relevant one:

<snip>
> Unlike SML, the OCaml language is not standardised and continues to
> evolve. The evolution of OCaml has allowed it to adopt many new
> programming constructs not found in SML, including polymorphic
> variants and objects. However, the evolution of the OCaml language
> sometimes renders old code uncompilable or, worse, different in terms
> of performance or even correctness.

>
>   Ray tracer language comparison
>
> /*Update: *Lisp much faster! Non-whitespace character counts!/
>
> We have ported four progressively optimised versions of our cut-down
> ray tracer
> <http://www.ffconsultancy.com/free/ray_tracer/comparison.html> to C++
> <http://gcc.gnu.org/>, Java <http://www.java.com>, OCaml
> <http://www.ocaml.org> and SML <http://www.standardml.org>. Joe
> Marshall, Nathan Baum, Juho Snellman, Jeffrey Siskind and others have
> kindly ported the programs to Common Lisp and Scheme. Thanks also to
> Oleg Trott for pointing out an important error in our code.
>
<snip>
>
> The OCaml and SML implementations of the ray tracer are by far the
> most succinct. The shortest OCaml implementation of the ray tracer
> fits in only 55 lines. The longer OCaml and SML implementations are
> significantly shorter and faster than the shortest implementations in
> all of the other languages.
>
<snip>
> In addition to examining the fastest implementations, it is
> interesting to look at the performance of simple implementations.
<snip>

>
> In 32-bit, Stalin-compiled Scheme is fastest, followed closely by the
> more concise MLton-compiled SML program. OCaml, SML/NJ-compiled SML
> and g++-compiled C++ all give similar performance. The Lisp is not
> only 30% more verbose than the OCaml but is also 4.9x slower.
>
> Given their performance, it is remarkable that the Stalin and MLton
> implementations are devoid of low-level optimisations and the C++ and
> OCaml implementations only had minor design decisions made based upon
> performance (the use of pass-by-reference in C++ and the
> representation of vectors as records rather than tuples in OCaml).
>
> Not uncoincidentally, two of the best optimising compilers, Stalin and
> MLton, are both whole-program optimising compilers, meaning they can
> only compile whole (self-contained) programs. The C++ and OCaml
> compilers allow partial recompilation, compile this whole program much
> more quickly and still achieve very competitive performance.
>
<snip>
> Note that OCaml and SML/NJ compile faster than all of the other
> languages and Stalin compiles the Scheme implementation three orders
> of magnitude slower than SML/NJ, taking over 10 minutes to compile
> this tiny program.
<snip>
> Unlike SML, the OCaml language is not standardised and continues to
> evolve. The evolution of OCaml has allowed it to adopt many new
> programming constructs not found in SML, including polymorphic
> variants and objects. However, the evolution of the OCaml language
> sometimes renders old code uncompilable or, worse, different in terms
> of performance or even correctness.




Reply | Threaded
Open this post in threaded view
|

Re: SML vs Ocaml for ECMA script spec.

Daniel C. Wang-2
The last  nail in the coffin. I can simply not imagine any organization
like ECMA forcing people to use the single GPL encumbered implementation
of Ocaml when there are free alternatives already available  from
multiple vendors. Unless you do the reference implementation without
referring to any of the OCaml library, my understanding is that you will
not be able to redistribute the *full* spec without encumbering the IP.
I'm sure the FUD around the GPL will slow down the standards process down.

> http://caml.inria.fr/ocaml/license.en.html
>    The Compiler is distributed under the terms of the Q Public License
> <http://caml.inria.fr/ocaml/license.en.html#qpl> version 1.0 with a
> change to choice of law (included below).
>     The Library is distributed under the terms of the GNU Library
> General Public License
> <http://caml.inria.fr/ocaml/license.en.html#lgpl> version 2 (included
> below).
>
> http://mlton.org/License
>  Software
>  As of 20050812, MLton software is licensed under the BSD-style
> license below. By contributing code to the project, you agree to
> release the code under this license. Contributors can retain copyright
> to their contributions by asserting copyright in their code.
> Contributors may also add to the list of copyright holders in
> doc/license/MLton-LICENSE, which appears below.
>
> http://www.smlnj.org/license.html
>   Yet another BSD style...
Having the spec in an executable form can greatly improve compliance,
because you can use the official spec as a test-oracle. Ideally, you
want to let people download and run the spec and integrated it into the
test process, and perhaps even make modifications to it. The GPL
wildcard will just impede this process and reduce the conformance
quality of any implementations.

Okay, I've spamed the list enough. I hope I've made a strong case that
the *right* pragmatic decision is to go with SML over Ocaml.

P.S. You guys obviously have enough taste to be thinking of using any ML
for the language spec. So, I'm sure after you review all the facts
you'll do the right thing again and choose SML.

Reply | Threaded
Open this post in threaded view
|

Re: SML vs Ocaml for ECMA script spec.

Brendan Eich-3
On Oct 21, 2006, at 2:02 PM, Daniel C. Wang wrote:

> P.S. You guys obviously have enough taste to be thinking of using  
> any ML for the language spec. So, I'm sure after you review all the  
> facts you'll do the right thing again and choose SML.

Flattery will get you everywhere ;-).

We are agreed now on SML, using SMLNJ.  Our flirtation with OCaml was  
based on convenience and familiarity, but as I noted in another  
message, we were committed to using a small core language, plus  
continuation support of some kind (for OCaml this meant a patch; with  
SMLNJ, no patch).

Dave will post to LtU soon, I'm sure.

/be


Reply | Threaded
Open this post in threaded view
|

Re: SML vs Ocaml for ECMA script spec.

Nicolas Cannasse
>>P.S. You guys obviously have enough taste to be thinking of using  
>>any ML for the language spec. So, I'm sure after you review all the  
>>facts you'll do the right thing again and choose SML.
>
>
> Flattery will get you everywhere ;-).
>
> We are agreed now on SML, using SMLNJ.  Our flirtation with OCaml was  
> based on convenience and familiarity, but as I noted in another  
> message, we were committed to using a small core language, plus  
> continuation support of some kind (for OCaml this meant a patch; with  
> SMLNJ, no patch).
>
> Dave will post to LtU soon, I'm sure.

Yes, the not-native support of continuations in OCaml would have maybe
been a problem. Even if I prefer OCaml - or even better my own NekoML ;)
- any language in the ML family should be enough powerful to express the
specification.

Nicolas

Reply | Threaded
Open this post in threaded view
|

Re: SML vs Ocaml for ECMA script spec.

Daniel C. Wang-2
In reply to this post by Brendan Eich-3
This is all great news. I hope you all know what a groundbreaking a step
this is in terms of the state of the art in language specification.

I wish you guys all the luck. In one of my pipe dreams someone sits down
and uses ML to specify something like the JVM or CLR next. Then of
course everyone reads the wonderfully concise specs that they can also
execute, and start wondering... why the hell am I programing in Java,
C#, or Javascript! :)  (okay, I'll admit these days that C# is looking
pretty cool too, if it only had datatypes...)

The history of ML was that it was the "scripting" language for a theorem
prover. At some point people realized that it was cool and useful on
it's own.

Brendan Eich wrote:

> On Oct 21, 2006, at 2:02 PM, Daniel C. Wang wrote:
>
>> P.S. You guys obviously have enough taste to be thinking of using any
>> ML for the language spec. So, I'm sure after you review all the facts
>> you'll do the right thing again and choose SML.
>
> Flattery will get you everywhere ;-).
>
> We are agreed now on SML, using SMLNJ.  Our flirtation with OCaml was
> based on convenience and familiarity, but as I noted in another
> message, we were committed to using a small core language, plus
> continuation support of some kind (for OCaml this meant a patch; with
> SMLNJ, no patch).
>
> Dave will post to LtU soon, I'm sure.
>
> /be
>
>