Arjun Guha, Claudio Saftoiu and Shriram Krishnamurthi have a recent paper on
the topic:
http://www.cs.brown.edu/~sk/Publications/Papers/Published/gsk-essence-javascript/
Having had some experience with this question myself, let me just say that
while formalization is appealing, it's a very subtle and time-consuming task.
Despite its well-known shortcomings, English is hard to beat for flexibility.
When it comes to hitting the right level of specification (not over- and not
under-), formalism can be frustratingly rigid. That includes more rigorous
approaches like operational semantics as well as reference implementations or
meta-circular definitions. As Graydon pointed out, you end up being forced to
choose concrete representations that over-specify, particularly with the choice
of data structures. Math gives you more wiggle-room, but it's still finicky and
much slower going than code. And even most research languages don't have fully
formalized semantics. [ Standard ML is about the only one I know of that is
100% formalized. Don't tell me Scheme is unless you want to hear me drone on
about my thesis. ;) ]
There are specific pitfalls to the meta-circular approach. As nice as it sounds
to just take a language that everyone already knows, you end up standing on a
delicate precipice. Fall over one side, and you accidentally leave implicit
parts of the semantics that never get defined. Fall over the other side, and
you end up spending all your time carefully defining the subset of ES that you
want to use for your defining language-- in which case, you've essentially
designed another language (one spec for the price of two!).
(I'm not saying improving the spec language is a bad idea, just trying to spell
out some of the challenges.)
Dave
On May 19, 2010, at 2:44 PM, Dirk Pranke wrote:
> I wonder if you can answer some of the metacircularity concerns by
> defining the necessary parts using operational semantics, as in
> http://jssec.net/semantics/sjs.pdf .
>
> As an aside, has anyone actually attempted to formally document the
> necessary kernel subset (apart from the above paper)?
>
> -- Dirk
>
> On Mon, May 17, 2010 at 4:03 PM, Graydon Hoare <gray...@mozilla.com> wrote:
>> On 17/05/2010 2:48 PM, Douglas Crockford wrote:
>>>
>>> I would like to see the next edition of the specification use the
>>> ECMAScript language to describe the ECMAScript language. I think this
>>> would significantly improve the likelihood that a programmer could
>>> correctly understand ECMAScript by reading the standard. I think that
>>> would make the web a better place. A strawman is in the wiki.
>>>
>>> http://wiki.ecmascript.org/doku.php?id=strawman:specification_language
>>
>> Some thoughts on this (as one of the authors of the ES4 RI):
>>
>> - The circularity hazards you mention are real, and were a large
>> reason why we "bottomed out" in SML. Unless you're expecting users
>> to take the fixpoint of the spec or something (which may not even
>> be unique) you will probably need to draw a line around a kernel
>> language that you define "some other way". SML has a denotational
>> semantics, which is why we picked it. I'm not suggesting you pick it
>> again (plenty of problems arose; mostly cultural) but I think you'll
>> get the most mileage here when describing the standard libraries,
>> and possibly the front-end, rather than the core concepts like
>> "evaluate expression" or "look up name".
>>
>> - There is already a fair quantity of code for both those bits
>> (library and front-end). ES4 libraries were being written in ES4;
>> Narcissus has a decent front-end and Mozilla has people working on
>> it still. Consider cribbing from these.
>>
>> - Another serious hazard (and strong-ish argument for drawing a line
>> around a non-self-defined kernel language) is the risk of
>> over-specification. It's easier to avoid in library code, much
>> harder when dealing with bits of the most-primitive semantics, which
>> differ quite a lot between different implementations of ES.
>>
>> - Be careful with legibility. Another (secondary) reason we settled on
>> SML is that it presented what we considered at the time to be a
>> relatively clean typographic quality and can be rendered as "not
>> very much like source code" with a certain amount of mechanical
>> translation and/or marked redaction work. We were repeatedly
>> warned that we would need to have a "natural language" translation
>> produced from the executable steps, on the basis that ISO and/or
>> ECMA would reject standards containing source and that "IP issues"
>> would substantially cloud and possibly derail the process if any
>> source code was proposed. Find out if this is a real problem before
>> you go too far down this road.
>>
>> -Graydon
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
