SML vs Ocaml for ECMA script spec.
danwang74 at gmail.com
Tue Oct 24 18:57:00 PDT 2006
BTW is there a way to run MLton in a "check the syntax and type mode only".
That would be a nice feature if you're just checking conformance with the
Also, I would hope the SML community at large steps up to support this
effort. If the preliminary spec is published via CVS/Subversion. I think it
would be good for all the SML implementations to try to add that spec to
their regressions. This would proivde the widest possible level of
conformance, and a strong gurantee that the spec runs on every/many SML
For that reason the idea of using Threads rather than call-cc might
encourage more SML implementors to add the spec to their regressions.
As for the style of the semantics. In an ideal world there would be a
high-level "natural" big-step semantics. This big-step semanitcs is best for
your "casual" progammer to undersand the spec. A very detaled "small-steps"
semantics would be useful and avoid the need for adding things like
Such a small-steps semantics maybe out of the charter of the current
standard, but there is nothing preventing some energetic folks to maintain a
small-step semantics in parallel with the "offical" spec. If the small-step
semantics is more unambigous, one might consider that the "offical" spec and
the big-step semantics the advisor commentary about it, or vice versa. But
that decsion can be sorted out at the end of the day.
The other great thing about using any programming langauge as a spec. rather
than a paper spec, is that we have great tools and models for collaborating
via programming languages. So, I hope everyone views this as a great
opporutinty to collaborate by investing resources and expertise when they
On 10/24/06, Dave Herman <dherman at ccs.neu.edu> wrote:
> > One can implement this signature using continuations, but it is also
> > easily implementable using MLton.Thread. The point being that you can
> > give a simple semantics to the meta-language extended with structure
> > Thread: THREAD, and then implement structure Thread using whatever
> > lower-level mechanism the particular SML implementation provides. And
> > readers of the ES4 spec don't have to understand the low-level stuff.
> It's an interesting idea, that we could pretend to be building on top of
> a native cooperative-threading semantics, which is actually implemented
> in terms of callcc. (I think it's what you were trying to say in your
> first email but I didn't pick up on it.) So casual readers have one
> level of abstraction they can use to think about it, and semanticists
> can see the lower level definition.
> OTOH, I'm not sure the extra level of abstraction is necessary.
> >> Certainly a pre-emptive threading system would make the sequentiality
> >> manifest.
> > I'm not sure what your point is here.
> Just basically the same thing you said: using a concurrent meta-language
> complicates the underlying semantics.
> > Going with SML/NJ is a fine choice. It's often what I use. I am
> > simply saying that you should also compile with another compiler
> > regularly, and from the start. It's not that hard. And if you don't,
> > you will shoot yourself in the foot, and not find out until much
> > later, after you have lost a lot of blood.
> Good advice, thanks. I'll give MLton a try.
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss