Fw: lexical 'super' in arrow functions?
On Sun, Dec 2, 2012 at 3:13 PM, Claus Reinke <claus.reinke at talk21.com>wrote:
First attempt got lost or stuck somewhere, trying again.
------------------------------**-------------------- From: "Claus Reinke" <claus.reinke at talk21.com> Sent: Thursday, November 29, 2012 10:02 PM To: <es-discuss at mozilla.org> Subject: lexical 'super' in arrow functions?
Is 'super' currently limited to method bodies, excluding local functions?
"super" is limited to ClassBody
Given that 'this' is lexical in arrow functions, I expected any enclosing 'super' to be available, as well, but I cannot confirm this from the spec.
Can you clarify... did you mean something like:
class Mine extends Array { constructor(...args) { this.foo = () => { super(...args); }; } }
?
This is from listening in on some of the TypeScript traffic, where people are running into all kind of issues when trying to use ES6 classes, btw.
I've been following all of the tickets and offering support wherever I can—I'd love to see the specific cases that you're referring to.
On Dec 2, 2012, at 12:13 PM, Claus Reinke wrote:
First attempt got lost or stuck somewhere, trying again.
From: "Claus Reinke" <claus.reinke at talk21.com> Sent: Thursday, November 29, 2012 10:02 PM To: <es-discuss at mozilla.org> Subject: lexical 'super' in arrow functions?
Is 'super' currently limited to method bodies, excluding local functions? Given that 'this' is lexical in arrow functions, I expected any enclosing 'super' to be available, as well, but I cannot confirm this from the spec.
Yes, clearly super should be able to be used in an arrow function that is lexically scoped to an enclosing super binding. The mechanism for describing this are mostly in the spec., but I just checked and there are a few loose ends that I will clean-up in the next spec. draft.
Whether anything besides a concise method in a class can have a super binding is something that still needs to be discuss. There are some uses, eg class-side methods that reference super that can not be expressed if super use is restricted to concise methods within class bodies.
This is from listening in on some of the TypeScript traffic, where people are running into all kind of issues when trying to use ES6 classes, btw. Claus
Do you have a link to the threads? Sounds interesting...
Is 'super' currently limited to method bodies, excluding local functions? "super" is limited to ClassBody
Yes, the question is about arrow functions in ClassBody.
Given that 'this' is lexical in arrow functions, I expected any enclosing 'super' to be available, as well, but I cannot confirm this from the spec. Can you clarify... did you mean something like:
class Mine extends Array { constructor(...args) { this.foo = () => { super(...args); }; } }
More likely in a non-constructor method, but yes.
This is from listening in on some of the TypeScript traffic, where people are running into all kind of issues when trying to use ES6 classes, btw.
I've been following all of the tickets and offering support wherever I can—I'd love to see the specific cases that you're referring to.
The majority of cases are just standard 'this' confusion, where the use of class syntax somehow gives people the impression that they don't have to worry about such aspects of JS.
Slightly more interesting are cases where class syntax is combined with method borrowing, often in higher-order function calls, losing the 'this' context while still inside the class body, ie
class { m1() { return this}; m2() { return [1,2].map(this.m1) }}
Both the above can usually be worked around by wrapping in arrows (eta-expansion), avoiding the depths of .bind/.call, and staying within the nice new higher-level syntax. I assume you've seen those discussions.
In the case that triggered this thread, the arrow wrapper does not work because TS currently takes a narrow view of where 'super' is permitted, excluding arrow functions nested in class bodies:
Claus
Is 'super' currently limited to method bodies, excluding local functions? Given that 'this' is lexical in arrow functions, I expected any enclosing 'super' to be available, as well, but I cannot confirm this from the spec.
Yes, clearly super should be able to be used in an arrow function that is lexically scoped to an enclosing super binding. The mechanism for describing this are mostly in the spec., but I just checked and there are a few loose ends that I will clean-up in the next spec. draft.
That would be good.
This is from listening in on some of the TypeScript traffic, where people are running into all kind of issues when trying to use ES6 classes, btw. Claus
Do you have a link to the threads? Sounds interesting...
TS traffic is somewhat distributed, and mixed between TS bugs, non-JS users not wanting TS to follow JS, and discussions actually relevant to ES development.
Still, it does seem to attract actual users to a language with ES6 features, and those are providing feedback and questions from trying to use these features on their current projects.
typescript.codeplex.com/discussions?searchText=this
typescript.codeplex.com/workitem/list/basic?issuesToDisplay=Open&keywords=bind
stackoverflow.com/questions/tagged/typescript
Remove the search keywords or try the RSS feeds to follow all traffic.
Claus
On Dec 3, 2012, at 2:00 AM, Claus Reinke wrote:
Is 'super' currently limited to method bodies, excluding local functions? Given that 'this' is lexical in arrow functions, I expected any enclosing 'super' to be available, as well, but I cannot confirm this from the spec.
Yes, clearly super should be able to be used in an arrow function that is lexically scoped to an enclosing super binding. The mechanism for describing this are mostly in the spec., but I just checked and there are a few loose ends that I will clean-up in the next spec. draft.
That would be good.
OK, I looked more closely and anything needed for super references within from within Arrow functions is already in the current draft. Just trace through the algorithms in section 11.2.4. Particularly, steps 1-4 of the Evaluation algorithms. However, I did add a few clarifying note in the next draft.
Is 'super' currently limited to method bodies, excluding local functions? Given that 'this' is lexical in arrow functions, I expected any enclosing 'super' to be available, as well, but I cannot confirm this from the spec.
Yes, clearly super should be able to be used in an arrow function that is lexically scoped to an enclosing super binding. The mechanism for describing this are mostly in the spec., but I just checked and there are a few loose ends that I will clean-up in the next spec. draft.
That would be good.
OK, I looked more closely and anything needed for super references within from within Arrow functions is already in the current draft. Just trace through the algorithms in section 11.2.4. Particularly, steps 1-4 of the Evaluation algorithms. However, I did add a few clarifying note in the next draft.
Before I make another attempt to extract this info from the current draft, let me some general comments:
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?").
Claus
That's related to a feature I have on my list to implement: cross-referencing actions in a step-through debugger/action record with their specific origin in the spec. So as you step into a function, see a sidebar scrolling by with Function Declaration Instantiation, multiple hits on Create(Mutable|Immutable)Binding, InstantiateArgumentsObject, Binding Initialization, etc.
On Dec 4, 2012 4:59 AM, "Claus Reinke" <claus.reinke at talk21.com> wrote:
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?").
Language specification is a difficult task, especially when handling a complex language, legacy spec style, and wide variety of audience background, not to mention a committee with lots of feedback and opinions. We are very lucky that Allen does the job he does.
That also means we shouldn't make it harder, or ask the spec to bear burdens it doesn't need to handle. JavaScript is blessed with numerous excellent books describing how to use the language and what various features are for, including Dave's new book. That's the place to go for description and explanation, not the spec.
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)?
Herby Vojčík wrote:
WHY / WHAT / HOW sections (with only HOW being normative)?
I've said it before: ECMA-357 (E4X) tried this and all it did was make more bug habitat in the informative sections, and confuse implementors who treated prose as normative and took its differences not as bugs, but as truth (either ignoring the normative spec pseudo-code, or thinking it wrong).
As Sam said, a spec cannot serve two masters. Pedagogy and more advanced studies require other tools. The first job of the spec is to normatively specify the language for implementors.
I look forward to Brandon's super-cross-referencing work!
On Tuesday, December 4, 2012 at 8:34 AM, Sam Tobin-Hochstadt wrote:
Language specification is a difficult task, especially when handling a complex language, legacy spec style, and wide variety of audience background, not to mention a committee with lots of feedback and opinions. We are very lucky that Allen does the job he does. That also means we shouldn't make it harder, or ask the spec to bear burdens it doesn't need to handle. JavaScript is blessed with numerous excellent books describing how to use the language and what various features are for, including Dave's new book. That's the place to go for description and explanation, not the spec. Sam
Agreed. Community members that care enough to know about and stay up to date with ES6 progress could work together with TC39 to create something similar to dmitrysoshnikov.com/ecmascript/es5-chapter-0-introduction
Anyone interested in working on something like this should contact me at this email address
There is a long history of people publishing annotated versions of language standards that add informative materials. The Ecma copyright even explicitly allows for this.
I think I've said before that there is an opportunity here for somebody to run with this idea for ECMAScript. You don't even need to have TC39 involved. (But there probably are T39 members, like Rick, who may want to contribute or even take the lead.)
I made a somewhat more....interestling colored and (to me) more readable version of the ES6 spec (previous one from last) using jorendorff's html rendition as a foundation. Some may find this interesting, and some may be blinded for life: benvie.github.com/es-spec-html
On Dec 4, 2012, at 1:54 PM, Brandon Benvie wrote:
I made a somewhat more....interestling colored and (to me) more readable version of the ES6 spec (previous one from last) using jorendorff's html rendition as a foundation. Some may find this interesting, and some may be blinded for life: benvie.github.com/es-spec-html
He-he, I kinda like it! Especially the algorithms, although I miss the outline numbering style.
Hopefully, someday I'll have time to straighten-out all of the Word styling disasters that have accumulated over 6+ editions. That should make life easier for various html renders.
Language specification is a difficult task, especially when handling a complex language, legacy spec style, and wide variety of audience background, not to mention a committee with lots of feedback and opinions. We are very lucky that Allen does the job he does.
Yes. That doesn't mean he should have to do everything alone, or that the results of his work shouldn't be useable for a wider audience. And documentation helps collaboration. Here's an illustrative example from another context:
I've recently been digging through non-trivial, insufficiently documented project source code (namely the TypeScript compiler and services). So have several others. Like a spec, the whole thing is completely specified by its source, but with just a few more high-level comments, we would have had a much easier time, would have wasted less time, and would be more certain of the understanding we've reached. More coders would have tried or more would have succeeded in building on the services, and earlier. There still isn't as much plugin developer uptake as the code itself warrants.
If you believe in commenting source code, you should believe in annotating the reference implementation that is the ES spec.
That also means we shouldn't make it harder, or ask the spec to bear burdens it doesn't need to handle. JavaScript is blessed with numerous excellent books describing how to use the language and what various features are for, including Dave's new book. That's the place to go for description and explanation, not the spec.
I'll try to answer several related concerns in one reply:
-
Back when I last looked at Standard ML, it had a formal definition and an informal, but official commentary
I don't want that - it explains the formalism, instead of the language
-
David Flanagan does a very nice job of providing an informal reference to the language (and its environment)
I hope he'll do it again for ES6, and the ES6 spec should not include all the useful text that he adds
-
There have been community efforts to explain or annotate the spec, and I hope there will be such efforts for ES6
This is getting closer, but represents more work than is needed for documenting the core spec
-
There are concerns about annotations (a) extending the failure surface and (b) being used instead of the normative parts
(a) yes, definitely want that! It is about saying the same thing twice, in different forms and level of detail. That means one can check for internal consistency, and file either a spec or a documentation bug.
(b) if implementors are tempted to "treat prose as normative", that only confirms that the normative formal parts are too difficult to interpret for normal JS hackers;
By all means, put the normative, formal parts first, then call the informal parts "notes on the spec", to avoid any genuine misunderstandings about which parts are normative; then community and tests need to ensure that engines implement spec, not notes.
What do I want, then? Well, good comments give intent and big picture instead of explaining the code. And some parts of the spec do have both already. So I'm mainly asking for very brief notes in the existing style (on language features, not on the formalism).
For instance, chapter 8 is all about the big picture, and the return (12.9) and with statements (12.10) have short notes explaining what they are about. This shows that no huge effort is needed.
Given that with was well on its way out of the language, and that
so many coders do not care about strict mode, there ought to be
an explanation that use of 'with' is discouraged, and why (it is
useful, but too powerful for its use cases).
However, right before that, the continue (12.7) and break (12.8) statements have no such explanatory notes. This shows that the level of documentation is not consistent, and that it is not just a question of focusing on the formalization of new features first.
Moving to new stuff, the only notes in arrow function definitions (13.2) are explanations of the formalism, the only notes about lexical this (never mind lexical super) in arrows are in the sections on *.forEach. The super keyword section (11.2.4) has no notes at all - if you were browsing the spec trying to figure out what super is about in JS, how much of the spec would you have to read to answer that question, and how many readers succeed?
So, I am not asking for great extra efforts, just for a couple of sentences indicating what each language feature section is trying to formalize. If the big picture sections exist and are readable, then simply using language NOTEs consistently everywhere would help.
Claus
On Wed, Dec 5, 2012 at 5:04 AM, Claus Reinke <claus.reinke at talk21.com> wrote:
if you were browsing the spec trying to figure out what super is about in JS, how much of the spec would you have to read to answer that question, and how many readers succeed?
This is a very clear statement of the problem -- browsing the spec to
figure out what X is about in JS is a bad idea. But that is as it
should be. The spec formally defines the language; it is not for
browsing to learn about the language. If you want to learn what a new
feature like super does, you'll want to read blog posts and
examples, until it appears in tutorials on the web, and then it will
appear in future versions of Dave Herman's or David Flanagan's or Doug
Crockford's books, if they decide to write them.
If you ask the spec to serve two masters, then it will do one badly. In the Scheme community, the existence of a spec that many people find to be a good introduction to learning the language has been actively bad for the future development of the language.
sam th samth at ccs.neu.edu
That's related to a feature I have on my list to implement: cross-referencing actions in a step-through debugger/action record with their specific origin in the spec. So as you step into a function, see a sidebar scrolling by with Function Declaration Instantiation, multiple hits on Create(Mutable|Immutable)Binding, InstantiateArgumentsObject, Binding Initialization, etc.
I've followed your occasional near-announcements with interest but cannot help the feeling that there is a great effort the purpose of which I do not fully appreciate yet. Sometimes it seems you understate what you've already implemented, at other times it seems as if this is mostly a fascinating project for you, with little concern about how other might find it useful.
Even as an executable version of the spec, it would be great to have. If single-stepping and cross-referencing helps program understanding, tool support for single-stepping through a cross- referenced spec should help getting used to the spec internals (not to mention helping to verify spec consistency).
Or am I misunderstanding again?-) Claus
It's a learning experience for me. I'm not formally trained, but I learn quickly when I realize there's a thing to learn.
I've built a thing thing that is now in need of a.) refinement, b.) optimization, and c.) usable interfaces built on it. I have intentions to build more than already exists, but what exists at least gives an indication of the direction. benvie.github.com/continuum
First attempt got lost or stuck somewhere, trying again.
From: "Claus Reinke" <claus.reinke at talk21.com>
Sent: Thursday, November 29, 2012 10:02 PM To: <es-discuss at mozilla.org>
Subject: lexical 'super' in arrow functions?