SML vs Ocaml for ECMA script spec.
dherman at ccs.neu.edu
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