On Jan 30, 2014, at 11:52 AM, Forrest L Norvell wrote: > On Thu, Jan 30, 2014 at 11:07 AM, Boris Zbarsky <[email protected]> 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. > > I agree with this entirely, with the caveat that "partially obscured" and > even "boilerplate" are in this case subjective factors. Once you split > Domenic's streams documentation into two pieces -- a narrative, informal > piece explaining the design and its motivation, and the specification proper, > which is still informal but more organized -- the specification itself seems > neither particularly verbose nor overdetermined. Again, this is my subjective > interpretation, but I've spent a fair amount of time dealing with > specifications (and, just to be clear, mostly not in the JavaScript world). >
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. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
