allen at wirfs-brock.com
Thu Jan 30 14:45:46 PST 2014
On Jan 30, 2014, at 11:52 AM, Forrest L Norvell wrote:
> On Thu, Jan 30, 2014 at 11:07 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> I think we all agree that ES-style specifications are in fact more straightforward to transcribe into an ES implementation.
> What is harder, in my experience, is understanding whether the specification actually says what it means to say and determining whether there are bugs in the specification. This arises to some extent from the core functionality being partially obscured by a fair amount of boilerplate.
Some of the boiler plate is just a legacy (go look at the ES3 spec) and I'm slowly eliminating some of the verbosity. But it is a fairly low priority task in the overall effort of finishing ES6.
> Neither WebIDL nor the style of ES-262 are formal specification languages, nor do they specify any kind of rigorous operational semantics. This isn't a problem, as that's not their purpose. Their purpose, as I understand it, is to facilitate the specification of behavior in such a way that a consensus can be formed as to whether a given implementation is congruent with a given design (and, more nebulously, the designers' intent).
> Now I agree this is somewhat subjective. Some people prefer to have all the complications explicitly written out, both in specifications and in code, while others prefer reusable tested black boxes that have certain defined behavior. The former approach is much more verbose and can thus hinder understanding of the big picture. The latter approach involves in-depth understanding of the black boxes to understand the details. In practice, both the WebIDL and ES styles use some mixture of the two; what differs is the exact set of black boxes used. The ES style black boxes are mostly more fine-grained than the WebIDL ones.
> I agree with this description, and I wish there were a way to support both approaches. Neither the declarative style of WebIDL nor the imperative style of ES-262 are good at capturing both at the same time. As designers and researchers we want to be able to point to the formal model and, if not prove, at least attempt to make strong assertions about particular behaviors or abstractions. As implementors, it's much easier to work from imperative descriptions of behavior, and the process of resolving the ambiguities during implementation will surface aspects of the design that are not obvious when looking at a declarative model.
The ES6 spec. is much more detailed and prescriptive than any other language specification I've ever been involved with. This is intentional and motivated by the fact that the interoperability expectations across multiple independently developed implementations of the language are much high than any other language I've ever encountered. In addition, the collective experience in TC39 is that if something (for example various edge cases) is under specified in an ES spec. then implementations will inevitably have observable differences and that some JS programmers will write code that is sensitive to the differences. Hence, ES6 tries to specify the handling of all edge cases and the ordering of all observable side-effects.
Other standards might choose to use common test cases or other techniques to ensure interoperability. That isn't the path TC39 has taken.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss