SML vs Ocaml for ECMA script spec.

Dave Herman dherman at
Tue Oct 24 14:19:18 PDT 2006

> I don't understand why meta-language continuations are necessary for
> the spec.  If performance really isn't an issue, why not express
> stacks/continuations as ordinary data structures and do whatever
> manipulations you want on them directly?  It would probably make the

We are looking for a middle ground between precision and readability. A 
direct-style interpreter has the benefit of being clearest and requiring 
no whole-interpreter modifications. Explicit continuations or evaluation 
contexts risk polluting a lot of the spec with mostly irrelevant detail.

Clearly, as you point out, the dangers in using features of the 
meta-language to model aspects of the object language are a) bugs due to 
impedance mismatches between the two and b) misunderstanding due to 
readers not understanding the implicit features of ML.

I think the benefits outweight the risk: the features of ML that we are 
using are few, and pretty standard. Exceptions and handlers are, at 
their core, simple and widely understood, and ML encodes only their very 
basic features. There's no notion of "finally", for example. To be sure, 
call/cc is a monster, but as Brendan has been saying we can at least 
"keep the monster in a box" by only using it in the one place where it's 
needed, not throughout the spec.

By contrast, explicit evaluation contexts would be needed nearly 
everywhere, and would often be superfluous.

Another nice aspect of this decision is that it's not hard to write a 
translator that takes an ML program with effects and translates effects 
into a pure ML program written in monadic style. Again, since our 
effects are few, this requires the definition of only one monad 
(something like exceptions + continuations + state). This may prove 
useful if we need to translate the evaluator into a form more amenable 
to theorem proving. We're not there yet, though. :)

> If you do decide to use meta-language continuations, I suspect that
> exceptions and threads really are enough.  You should consider using
> (a very small subset of) MLton's thread interface:

I've already written an example implementation of yield in terms of 
Concurrent ML threads using SML/NJ. I guarantee sequentiality via a 
simple protocol through a single channel shared between the main thread 
and the generator thread.

Certainly a pre-emptive threading system would make the sequentiality 
manifest. Either way, it's a relatively small part of the spec -- again, 
the monster's in a box. :)

You're also quite right that using callcc for yield might be swatting 
flies with a bazooka. I'm experimenting with the two to see which I find 
clearer. Ah, the beauty of signatures and functors! It's such a pleasure 
working with ML.

> Now, for a few comments on the choice of SML implementation.

I really appreciate all your input. In fact, I imagine we will be 
*almost* ML-implementation agnostic. Given your warnings, maybe that's 
naive -- I'm sure you have far more experience with this than I. But 
right now we need to move forward, so for the moment I think we're going 
to go with SML/NJ. However, the libraries are remarkably similar, and 
the vast majority of our code will just be using the simple, core 
features of SML. So porting to a different implementation at some point 
isn't out of the question.



More information about the Es4-discuss mailing list