lexical 'super' in arrow functions?
herby at mailbox.sk
Tue Dec 4 07:40:17 PST 2012
Claus Reinke wrote:
> Like everyone else on this list, I have grown familiar with the current
> spec - not as familiar as tc39 members, but enough to find answers
> to questions when I need them.
> But with the evolving drafts of the new spec, I'm back in the situation
> most JS coders are wrt the spec: trying to find answers in the spec is
> just a little demoralizing, often unsuccessful, and will remain a hidden
> art for those who do not read/study most of it at some point.
> Language specs, for those languages that have them, fall somewhere
> on a scale from informal, readable to formal, unreadable.
> ES, for all its faults, has a spec on the formal side -which is a very
> good thing!- but unfortunately also on the not directly readable side.
> The reason is that the spec is essentially a reference implementation -
> even though it doesn't use a formal language, it consists of "what to
> do with this piece of code" instructions. Understanding these
> instructions requires knowledge and understanding of the reference
> machine code patterns, instructions and system libraries.
> This makes the spec not so useful for quick lookups or for
> understanding what those language features are for.
> It would enhance the usefulness of this important asset -the spec-
> if each section would start with one or two informal paragraphs
> on the most salient points of each feature.
> The formal parts would still be there to confirm the details, to guide
> implementers, and as the normative part of the spec. But the informal
> parts would make quick lookups succeed, would give guidance on
> what is being formalized, and would support program construction
> ("what is this good for?" rather than just "how do I implement this?").
WHY / WHAT / HOW sections (with only HOW being normative)?
More information about the es-discuss