Continuing woes in reading the ES6 spec language

Oliver Hunt oliver at
Thu Sep 12 09:49:17 PDT 2013

On Sep 12, 2013, at 7:51 AM, Andreas Rossberg <rossberg at> wrote:

> On 12 September 2013 01:41, Allen Wirfs-Brock <allen at> wrote:
>> For now, I'm going to try giving each semantic routine in a subsection, a section number.  Note this may include multiple algorithms corresponding to various productions.  I'll also add a "see also" under each such heading that references other subsections that implement the same semantic action for other productions.  That should make it easier to navigate to all implementation of, for example, "BindingInitialisation".
>> What we have here is a highly polymorphic nonlinear program and as old Smalltalker knows, the best way to find your way around is at any reference to a name to be able to popup a navigable list of both implementaors and callers of that name.  Maybe that's something we could get working in the HTML version.  We're already halfway there with some of the definition links.
> Well, yes, but just to be clear, the readability problems are not due
> to polymorphism or non-linearity as such but mainly due to OO-style
> decomposition. That is simply not a good match for a language spec (to
> put it mildly). Tool support may be a viable work-around for dealing
> with code, but not for something whose primary communication form is
> in (physical or virtual) print.

I absolutely agree with this - the primary user of the spec document is implementers and ES developers, not tools.  For that reason the spec should be tailored to human readers, with machine readability seen as a nice optional extra.

> A spec is a system which (a) wants to be transparent (as opposed to
> encapsulated), and (b) is pretty much closed-world (extension points
> notwithstanding). Consequently, none of the advantages of OO apply,
> and it becomes primarily a barrier.
> (I'm not proposing any change to that at this stage, obviously. But it
> is a growing technical debt that we might consider clearing at some
> point.)

I disagree here, a spec that is hard to read, is a spec that is hard to implement correctly.  It doesn't matter if it is technically unambiguous if it is hard enough to read that an implementer can't determine what the unambiguous behavior is.

I've spent a lot of time now trying to read this spec, and have still not been able to determine the semantics of a number of the new language features.  I guess it's possible i'm just being thick, but I'd like to imagine that after so many years I know how to read and implement a spec.

> /Andreas


> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list