Re: Inner functions and outer 'this' (Re: That hash symbol)
On Mar 31, 2011, at 10:32 AM, Kam Kasravi wrote: How reasonable would it be to treat 'this' in a similar way that the prototype chain is referenced when resolving identifiers? I realize there would be ambiguity for like named identifiers but that problem exists now... In Allen's first example this.handleClick(this,e) would not be resolved with it's implicit binding to elem, so 'this' would be bound lexically and the code would just work. The second 'this' would of course default to the implicit bindin Other languages have tried to integrate inheritance based binding with lexical binding. See f http://dyla2007.unibe.ch/?download=dyla07-Gilad.pdf and http://bracha.org/newspeak-modules.pdf for one example and additional references. There are some complications to this approach and it seems to me that it is unlikely to be something that could be retrofitted in JavaScript. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
Thank you Allen for the references and analysis. It's interesting that Gilad argues resolution should be lexical followed by inheritance to avoid 'unanticipated name capture' that may exist within the inheritance chain. Probably even less of an option given backward compatibility requirements. On Mar 31, 2011, at 11:12 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Mar 31, 2011, at 10:32 AM, Kam Kasravi wrote How reasonable would it be to treat 'this' in a similar way that the prototype chain is referenced when resolving identifiers? I realize there would be ambiguity for like named identifiers but that problem exists now... In Allen's first example this.handleClick(this,e) would not be resolved with it's implicit binding to elem, so 'this' would be bound lexically and the code would just work. The second 'this' would of course default to the implicit bindin Other languages have tried to integrate inheritance based binding with lexical binding. See f http://dyla2007.unibe.ch/?download=dyla07-Gilad.pdf and http://bracha.org/newspeak-modules.pdf for one example and additional references. There are some complications to this approach and it seems to me that it is unlikely to be something that could be retrofitted in JavaScript. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Tue, Mar 29, 2011 at 7:08 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Mar 29, 2011, at 3:03 PM, Sam Tobin-Hochstadt wrote:
On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
JavaScript up to this point seems to have done a pretty good job of
balancing the OO and functional perspective within the language. However, I
think removing the specialness of this and the implicit this parameter
may be a step too far that breaks that balance.
I disagree with the idea that this is changing the balance. Brendan
has responded at length about the proposals, but I wasn't talking at
all about removing the distinguished first argument. For example:
function f(mythis | x, y) { ... }
is very much in the OO tradition of distinguishing the receiver --
it's just using lexical scope for disambiguation.
(I think you just reinforced the point I was trying to make. You prioritize
the use of lexical scoping over a single unambiguous distinguished meaning
for this)
I think what would change the balance would be not continuing to have this
serve as the implicit default for the name of the distinguished receiver. In
particular for
#f(x,y) {this.foo(x,y)}
when such definitions occurs in a method like context such as method1,
method2, and getter below:
First, I think that the major problem here is that we're talking about
two issues together: #-functions and lexical |this|. I think we
should resolve these separately -- there's no reason they have to go
together. That's not to say that I think #-functions without an
implicit bindings are necessarily a bad idea, just that it's a
separate issue.
[snip]
Optionally allowing explicit use of an alternative receiver name is probably
acceptable as long as there is a default name. The OO tradition is to
distinguish the receiver by using a fixed distinguished name, not to provide
a distinguish place for arbitrarily naming the receiver. Python and various
lisp object systems allow arbitrary receiver naming, but they have arguably
never been in the mainstream of object-oriented language design. If you take
away the special meaning of this and you don't have alternative vocabulary
such as Smalltalk does to talk about the receiver of a method then you
don't have a simple common way to talk about the object on which the method
was invoked and that is an essential concept in the OO tradition.
Second, I think this is taking a pretty narrow view of the OO
tradition. In particular, writing Python (a fairly popular language,
these days :) and Flavors (from the same decade as Smalltalk) out of
the mainstream seems pretty extreme.
--
sam th
sa...@ccs.neu.edu
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Mar 30, 2011, at 5:06 AM, Sam Tobin-Hochstadt wrote: On Tue, Mar 29, 2011 at 7:08 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: [snip] Optionally allowing explicit use of an alternative receiver name is probably acceptable as long as there is a default name. The OO tradition is to distinguish the receiver by using a fixed distinguished name, not to provide a distinguish place for arbitrarily naming the receiver. Python and various lisp object systems allow arbitrary receiver naming, but they have arguably never been in the mainstream of object-oriented language design. If you take away the special meaning of this and you don't have alternative vocabulary such as Smalltalk does to talk about the receiver of a method then you don't have a simple common way to talk about the object on which the method was invoked and that is an essential concept in the OO tradition. Second, I think this is taking a pretty narrow view of the OO tradition. In particular, writing Python (a fairly popular language, these days :) and Flavors (from the same decade as Smalltalk) out of the mainstream seems pretty extreme. -- Sam, I don't want to battle over this, but I think I had as good of an insider's view as anyone during the development of practical OO during its heydays in the 80's and 90's. The Lisp object dialects were at the fringes of the object-oriented world, they were invited to the family gathering but were largely in their own world . Arguably Flavors and its Lisp cohorts had more influence on the emergence of AOP than on the evolution of mainstream OO. Python was a late comer that only began to gain traction in the mid-90's. It had no impact on classic OO thought or language designs. Much bigger influences although never widely used were Simula 67 (obviously) and Eiffel. The most influential OO language all had static class declaration and a single distinguished way to refer to the current method receiver (self, this, Current). BTW, Guido has a nice article on the how classes originally emerged in Python: http://python-history.blogspot.com/2009/02/adding-support-for-user-defined-classes.html Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On 2011-03-29, at 17:52, Allen Wirfs-Brock wrote: On Mar 29, 2011, at 1:12 PM, P T Withington wrote: If I had a vote, it would be for a way to explicitly name the `-1th` argument to a function. And I would wish for it to be available in all function forms, defaulting to using the legacy name `this`, if not otherwise specified. I believe it not only addresses the issue in this thread, but leaves the way open for generic functions. [As a user, I infer I fall into your functional proponent camp, but I claim to also be an o-o proponent. I just find it much easier to think in generic functions and consider the distinguished receiver of message passing as being a degenerate case of that, which has a layer of syntactic sugar to let you express foo(a, b, c) as a.foo(b, c), if you like to think the other way.] Yes, the generic function camp largely coming out of the Lisp world has always been much more closely assigned with the functional world than with the object-oriented world. To us objectivists a.foo(b,c) really does carry a very different meaning than foo(a,b,c). The OO design process centers on identify the objects that will make up a system, not the functions that make up the system. While I appreciate this is a religious battle, IWBNI there were a solution that allowed alternative religions, rather than only the mainstream one. Hence my vote. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On 2011-03-29, at 17:38, Brendan Eich wrote:
[...]
We did not discuss allowing |this| to be bound otherwise, *except*
#foo(this = this| arg1, arg2) {...}
Am I right in understanding the above to be an idiom for trampolining the outer
`this` binding into the closure? (With the hazard that someone could override
that binding.) Or are you just giving an example, not endorsing a particular
idiom?
[...]
The other use-case, what Alex Russell calls soft-bind, also wants |this| not
|^this|.
Is there an example of what 'soft-bind' means somewhere?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
If I've got this right, the idea of soft bind is that the function
distinguishes whether it's called as a function or as a method; if called as a
function, it uses the lexical binding of |this|, and if called as a method, it
uses the dynamically pass-in binding of |this|.
Note that the .call and .apply methods don't allow you to make this distinction.
Dave
On Mar 30, 2011, at 1:14 PM, P T Withington wrote:
On 2011-03-29, at 17:38, Brendan Eich wrote:
[...]
We did not discuss allowing |this| to be bound otherwise, *except*
#foo(this = this| arg1, arg2) {...}
Am I right in understanding the above to be an idiom for trampolining the
outer `this` binding into the closure? (With the hazard that someone could
override that binding.) Or are you just giving an example, not endorsing a
particular idiom?
[...]
The other use-case, what Alex Russell calls soft-bind, also wants |this| not
|^this|.
Is there an example of what 'soft-bind' means somewhere?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
See http://wiki.ecmascript.org/doku.php?id=strawman:soft_bind for the
method-API proposal.
/be
On Mar 30, 2011, at 2:11 PM, David Herman wrote:
If I've got this right, the idea of soft bind is that the function
distinguishes whether it's called as a function or as a method; if called as
a function, it uses the lexical binding of |this|, and if called as a method,
it uses the dynamically pass-in binding of |this|.
Note that the .call and .apply methods don't allow you to make this
distinction.
Dave
On Mar 30, 2011, at 1:14 PM, P T Withington wrote:
On 2011-03-29, at 17:38, Brendan Eich wrote:
[...]
We did not discuss allowing |this| to be bound otherwise, *except*
#foo(this = this| arg1, arg2) {...}
Am I right in understanding the above to be an idiom for trampolining the
outer `this` binding into the closure? (With the hazard that someone could
override that binding.) Or are you just giving an example, not endorsing a
particular idiom?
[...]
The other use-case, what Alex Russell calls soft-bind, also wants |this|
not |^this|.
Is there an example of what 'soft-bind' means somewhere?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Mar 28, 2011, at 10:35 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 27, 2011, at 11:13 AM, David Herman wrote:
To be fair, your suggestion is more moderate than de Bruijn, although it's
not clear whether you're proposing the ability to refer to shadowed bindings
of *all* variables or just |this|. If it's the former, I'm *strongly*
opposed. If it's the latter, well, I guess I'm still pretty opposed, just
maybe less strongly. :)
Dave, I think that applying this solution to the this-scoping issue may be a
really good idea
Claus, thanks from bringing a new (old) idea into the discussion.
I agree with Dave about all the fragility issues he mentioned for the general
case. Also, I just don't see the general problem (if it is even a problem)
as one that is important enough to try to fix in the language since it is
probably rare and it can be avoided by careful naming.
However, the specific case of 'this' is a different matter.'this' is
implicitly rebound in every function scope and the JavaScript programmer has
no direct control over the naming and shadowing. The result is that they
have to know and use the self renaming pattern.
This issue shows up enough in defining objects via object literal methods and
in methods that call higher order functions that it is something that may
well be worth addressing in the language. Particularly as we discuss adding
additional declarative forms to Harmony that included nested method
definitions. The outer 'this' problem is limited enough that we can avoid
things like dynamic scoping complications in the solution. Also it is
limited enough that I don't believe that the solution imposes refactoring
complications.
Here is a sketch of a proposal:
^this is added as a new lexical token of the language. When spoken it is
pronounced as outer this . In the expression grammar ^this is a primary
expression.
It is a syntax error for ^this to appear outside of a function body. It may
not occur at the top level of a program.
When evaluated, the value of ^this is the this binding of the function that
immediately lexically encloses the function body that contains the ^this. It
is a early syntax error if there is no such function. For example:
//at the top level
var self = ^this; //syntax error, at the top level
function foo() {
^this.bar(); //syntax error, no enclosing function
}
The two primary use cases for ^this are exemplified by the following two
examples:
MyObj.prototype.addClickHandingForElement(elem) {
elem.addEventListener('click', function (e) {^this.handleClick(this,e)});
}
This does provide an elegant solution but perhaps for a somewhat uncommon
problem. Today I think most would do the following (if not using self):
MyObj.prototype.addClickHandingForElement(elem) {
elem.addEventListener('click', this.handleClick.bind(this))
}
Where the event.target would be used in the context of handleclick. I've
noticed that coffescript uses this= to autobind but not disambiguate. One
possible alternative would be to have a keyword modifier similar to your
suggested method called callback which autobinds this. From a declarative
viewpoint it would be clear what methods within the type were intended to be
used in this way. Although it would not handle the inner outer this use case.
Your second example below I would of done as:
MyObj.prototype.wrap = (function (wrapper) {
// create a wrapper object that limits access to the properties of one of my
objects
return {
name: this.id, //fix name of wrapper at creation (uses this of wrap call
get foo () {return wrapper.foo}, //outer this is this of wrap call
set bar(val) {wrapper.bar = val} //outer this is this of wrap call
})(this);
even if ^this were available since I would find it clearer. At least in my
experience I do not run into many scenarios where both this and ^this are
accessed in the same context, but I do use/find many scenarios where callbacks
should be bound especially when custom events are used liberally or within
node. In those cases where I need both I tend to curry the inner this and
provide it as a parameter to the outer callback. Somewhat contrived for the
first example since elem is available in the event but it would look like
elem.addEventListener('click', this.handleClick.bind(this).curry(elem))
assuming curry was available on the Function prototype.
MyObj.prototype.wrap = function () {
// create a wrapper object that limits access to the properties of one of
my objects
return {
name: this.id, //fix name of wrapper at creation (uses this of wrap
call
get foo () {return ^this.foo}, //outer this is this of wrap call
set bar(val) {^this.bar = val} //outer this is this of wrap call
}
Note that only one level outer this access is supported, ^^this would be a
syntax error. In the rare cases where
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Tue, Mar 29, 2011 at 12:12 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: (I think I'm the only one to use the syntax ^this in a proposal so I'm not sure where 1,3,4 (at least using ^this syntax) came from. Well, I wasn't sure if you meant 1 or 2, and other people had suggested 3 and 4 (but I think using # instead of ^). Personally, I think that a way to name the implicit binding of the receiver would be better than adding more hardcoded names to the standard. The |^this| proposals seem problematically implicit, especially since we had quite reasonable suggestions (at the meeting at least) for naming |this| explicitly instead. The reason I really like ^this is it co-exists very nicely with the existing fixed implicit this binding. It address the primary scoping issue that arises from that implicit binding. Unlike the explicit this naming forms that have been discussed it would work in all function definition forms without adding any new header syntax to any of the function definition forms. I agree entirely that it goes with the existing fixed implicit |this| binding -- I just think that cuts the other way. The reason we're having this discussion is that the existing behavior of |this| isn't always what you want, and is hard to get around because of its fixed and implicit nature. I think we should alleviate *that* problem, not just the worst symptom. -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On 2011-03-29, at 08:52, Sam Tobin-Hochstadt wrote: I agree entirely that it goes with the existing fixed implicit |this| binding -- I just think that cuts the other way. The reason we're having this discussion is that the existing behavior of |this| isn't always what you want, and is hard to get around because of its fixed and implicit nature. I think we should alleviate *that* problem, not just the worst symptom. Way back in https://mail.mozilla.org/pipermail/es-discuss/2008-August/007273.html I raised the `this` problem: When you write a function you can choose the names of all your parameters (for maximum legibility of your code) except the implicit one, where you are forced to accept the name `this`. If you could specify a different name, specifying which implicit binding you meant in the presence of multiples would be simplified. I won't propose a syntax for specifying an alternative name for `this`, for fear of being taken out to the (bike)shed and getting caned, but I do think it worth considering: why must that implicit parameter have a fixed name? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
This is what Sam is referring to -- we've been talking about exactly such a feature. I continue to believe that something like the ^this feature we've been talking about is as likely to introduce bugs as it is to fix bugs. It's like special language support for off-by-one errors. Dave PS A propos of nothing, the ^this syntax probably doesn't work because of ASI; try parsing: x = y ^this.foo() On Mar 29, 2011, at 6:47 AM, P T Withington wrote: On 2011-03-29, at 08:52, Sam Tobin-Hochstadt wrote: I agree entirely that it goes with the existing fixed implicit |this| binding -- I just think that cuts the other way. The reason we're having this discussion is that the existing behavior of |this| isn't always what you want, and is hard to get around because of its fixed and implicit nature. I think we should alleviate *that* problem, not just the worst symptom. Way back in https://mail.mozilla.org/pipermail/es-discuss/2008-August/007273.html I raised the `this` problem: When you write a function you can choose the names of all your parameters (for maximum legibility of your code) except the implicit one, where you are forced to accept the name `this`. If you could specify a different name, specifying which implicit binding you meant in the presence of multiples would be simplified. I won't propose a syntax for specifying an alternative name for `this`, for fear of being taken out to the (bike)shed and getting caned, but I do think it worth considering: why must that implicit parameter have a fixed name? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Mar 29, 2011, at 7:26 AM, David Herman wrote: This is what Sam is referring to -- we've been talking about exactly such a feature. Sorry if that wasn't clear: at the last face-to-face we talked about allowing you to give your own custom name for the |this|-parameter, so that you could continue to refer to outer-bound |this|. This would use good ol' lexical scope, instead of exotic scope-crawling indices. Dave I continue to believe that something like the ^this feature we've been talking about is as likely to introduce bugs as it is to fix bugs. It's like special language support for off-by-one errors. Dave PS A propos of nothing, the ^this syntax probably doesn't work because of ASI; try parsing: x = y ^this.foo() On Mar 29, 2011, at 6:47 AM, P T Withington wrote: On 2011-03-29, at 08:52, Sam Tobin-Hochstadt wrote: I agree entirely that it goes with the existing fixed implicit |this| binding -- I just think that cuts the other way. The reason we're having this discussion is that the existing behavior of |this| isn't always what you want, and is hard to get around because of its fixed and implicit nature. I think we should alleviate *that* problem, not just the worst symptom. Way back in https://mail.mozilla.org/pipermail/es-discuss/2008-August/007273.html I raised the `this` problem: When you write a function you can choose the names of all your parameters (for maximum legibility of your code) except the implicit one, where you are forced to accept the name `this`. If you could specify a different name, specifying which implicit binding you meant in the presence of multiples would be simplified. I won't propose a syntax for specifying an alternative name for `this`, for fear of being taken out to the (bike)shed and getting caned, but I do think it worth considering: why must that implicit parameter have a fixed name? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Mar 29, 2011, at 7:26 AM, David Herman wrote: PS A propos of nothing, the ^this syntax probably doesn't work because of ASI; try parsing: x = y ^this.foo() I specified that ^this was a lexical token so I ASI should work fine. But you would have to say y ^ /'*whitespace*/ this.foo() if you wanted xor which is a breaking syntax change. I suppose we could use the universal # solution and make it #^this although that is less visually attractive. allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
I am really astonished to hear protection keys being thought of as brittle under transformation: that is just the opposite of what they are about! Sorry to astonish you. :) No problem!-) I was just afraid of the idea being misunderstood or being associated with fear-inducing phrasing, either of which can easily derail a discussion in which good ideas can otherwise speak for themselves. By the time we have agreed to what extent the concerns remain valid or can be alleviated, the rest of the community may well have stampeded away in panic! Not that this group necessarily works that way, of course, just general human nature:-) - Berkling's protection keys add flexibility to name-based schemes, *removing* their brittleness under transformation; it combines suitability for automated transformation with readability for humans (in fact, both de Bruijn's and the classical name-based scheme are special cases of Berkling's) Well, you're just asserting that Berkling's keys remove their brittleness without evidence. Ah, ok - I have been trying to summarize the idea on its own, using evidence-by-logic rather than by-reference or by-example, to avoid going through the history of Berkling style reduction systems on this list (it has been a while, but I would be happy to explain a bit if that would be of interest/appropriate here[*]). From your other comments I infer that you understand how the scheme works but also that you are still lumping together the various related schemes that have been used in this context. The latter might keep you from seeing what is different about Berkling's scheme, and hence how the brittleness is removed, by straightforward technical means (no magic or subjectivity). Since this seems to be relevant information for a language- specific design/spec discussion list talking about bindings, I'll try to outline the process (even as a rough proof outline, it beats more examples, as far as evidence is concerned). For those of you not interested in reduction: the same issues arise in refactoring. From memory (please excuse any errors): Church's original lambda-K calculus was meant to pin down the scoping issues that mathematicians and logicians encountered; it had partially defined conversion rules (in case of naming conflicts, the rules were simply not applicable), so one had to choose a suitable sequence of renamings (alpha rule) and conversion (beta rule) to ensure that such conflicts and rule failures were avoided. That is brittle in the strictest sense. Later presentations of lambda-calculus mixed a bit of renaming into conversion (either in beta reduction or in substitution). That leads to uncontrolled renamings of bound variables, to bypass the conflicts. That is not nice, and it is brittle wrt programmer-chosen names. Berkling's version just acknowledges that lambda calculus is missing some of the terms that would allow to represent the binding structures that can arise during conversion. The consequence of having too few terms to represent all intermediate results of reduction is that one either has to avoid the conversion sequences that lead into those holes (leading to partially defined reduction rules), or one has to put the available terms to double use (leading to conflicts between programmer intent and implementation needs, as far as names are concerned). Adding the missing terms gives the manoeuvring room to define the conversion rules fully, without gaps and without having to resort to renaming. So brittleness under transformation, in both senses, is avoided. De Bruijn's scheme doesn't help there: it has even fewer terms than Church's (only a single term representing all alpha-equivalent ones). Similar shortcomings seemed to apply to most other related schemes I've seen - most of them work technically but fail pragmatically. Berkling's extra terms do not add error-prone complexity in terms of binding structure, because other terms with equivalent binding structure already exist in Church's version. The extra terms are just designed in such a way that both binding structure and programmer-chosen names can be preserved during program transformations. And I'm afraid I've seen enough evidence in my experience to make me doubt your claim. Does the above help? We have to be careful not to confuse the new thing is different with the new thing is brittle. In this case, the new system has more complex rules can actually mean the new system is easier to use in practice, because the new rules have fewer exceptions. Just take a look at what happens to the definition of alpha- conversion in a language with Berkling's keys. Traditionally, when you alpha-convert a binding x, you can stop the induction whenever you hit an inner binding (shadowing) of x. Not so with your proposal: now you have to keep going
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Mar 29, 2011, at 7:28 AM, David Herman wrote:
On Mar 29, 2011, at 7:26 AM, David Herman wrote:
This is what Sam is referring to -- we've been talking about exactly such a
feature.
Sorry if that wasn't clear: at the last face-to-face we talked about allowing
you to give your own custom name for the |this|-parameter, so that you could
continue to refer to outer-bound |this|. This would use good ol' lexical
scope, instead of exotic scope-crawling indices.
Yes, and there was considerable debate at the meeting on the desirability of
the |this| solution (see Waldemar's notes) . ^this is an alternative proposal.
We probably need to directly compare the two and some of the objections to each.
Overview of proposals
this| - mandatory explicit naming of implicit this parameter
The original discussion in January added explicit naming and lexical scoping of
the implicit this parameter to # function declarations. In January we didn't
settle on a syntax but in March we seem to be converging on something like:
#foo(self | arg1, arg2) {...}
in the body of the above function, self would be bound to the implicit this
parameter of the function and this would resolve to any lexically enclosing
declarations of this or would be undefined if there were none.
It isn't clear whether or not arbitrary declarations of this would be allowed
within such functions or whether this could only be bound in a this |
context.
I believe that the intent of the proposal was that if you actually want to use
this to refer to the implicit parameter you would have to explicitly declare
it as:
#foo(this | arg1, arg2) {...}
and that a declaration such as
#foo( arg1, arg2) {...}
would not have a local binding for this and its implicit parameter would be
inaccessible.
In the original discussion the this| declaration was only applied to
#-functions. All other function declaration forms would continue to reserve the
meaning of this as a reference to the implicit parameter of the immediately
enclosing function.
However, using the this| syntax it would probably be possible to extend the
already existing function declaration forms:
function foo(self | arg1) {};
({get prop(self |) {} })
new Function(self | arg1, return 42');
etc.
However for backwards compatibility, if the | was not present in these legacy
forms they would have to fall back to the legacy implicit this binding.
^this - explicit one-level outer this reference
In this proposal ^this is a lexical token that may occurs as a
PrimaryExpession. It is interpreted as a reference to the implicit this
parameter of the outer function that immediately encloses the function body
containing the ^this token. In other words, it access the implicit this
binding that is lexically one level further out than the current implicitly
binding of this.
It is a early error to use ^this in any context where there isn't an outer
function that encloses the the ^this reference.
this remains a reserved word in all function declaration forms that refers to
the implicit this parameter. It can not be used as the identifier in any
declaration.
Pros and Cons for Each Proposal
this| Pros
It makes the implicit this parameter explicit.
Normal lexical scoping rules apply to this.
It is similar to Python and perhaps other functional OO languages.
It allows arbitrary deep access to the implicit this parameter of outer
functions.
It takes a lexically scoped functional view rather than a OO view of methods.
this| Cons
It requires a new function declaration form.
The meaning of this will be different in functions declared using various
forms.
Most methods only need the inner implicit this, yet they are forced to choose
between:
function() {}
#(this|){} //net saving only 4 chars.
Self-calls are no longer lexically explicit, you have to look at the function
header to recognize one
Refactoring hazard when moving statements containing self-calls between methods.
It is a solution that is more general than is needed to address the primary
use cases at issue.
It remove the this object from the vocabulary for talking about methods.
What is the new terminology for the implicit method parameters?
It takes a lexically scoped functional view rather than a OO view of methods.
^this Pros
It doesn't change anything about existing conventions for the implicit this
parameter or this references.
It works equally well with both new and legacy function declaration forms
It address the primary use cases for outer this access without adding seldom
needed generality
Consistency: this always means this; self-calls are always lexically
explicit
It takes a classic OO view of methods .
^this Cons
Overloads ^ character; maintaining backwards compat with expressions like
foo^this.bits would require parsing hackery.
May need to use #this, @this, or #^this instead.
It doesn't handle more than one level of function nesting.
It isn't like Python
It preserves the
Re: Inner functions and outer 'this' (Re: That hash symbol)
On 2011-03-29, at 14:19, Allen Wirfs-Brock wrote: I'll leave it to reader to weigh the above pros and cons. But I do have a closing statement: There is a decades long disagreement among designers/users of function and object-oriented languages. OO proponents think there is something special about the receiver of a method call and that self-calls have special significance. If I had a vote, it would be for a way to explicitly name the `-1th` argument to a function. And I would wish for it to be available in all function forms, defaulting to using the legacy name `this`, if not otherwise specified. I believe it not only addresses the issue in this thread, but leaves the way open for generic functions. [As a user, I infer I fall into your functional proponent camp, but I claim to also be an o-o proponent. I just find it much easier to think in generic functions and consider the distinguished receiver of message passing as being a degenerate case of that, which has a layer of syntactic sugar to let you express foo(a, b, c) as a.foo(b, c), if you like to think the other way.] ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Mar 29, 2011, at 11:19 AM, Allen Wirfs-Brock wrote:
The original discussion in January added explicit naming and lexical scoping
of the implicit this parameter to # function declarations. In January we
didn't settle on a syntax but in March we seem to be converging on something
like:
#foo(self | arg1, arg2) {...}
That's what I wrote on the white board last week at the meeting, yes. It's not
set in stone but I'm warmest to it (which is why I threw it up! ;-).
Alternatives include
#foo(self . arg1, arg2) {...}
where . is a play on how |this| comes from the base object to the left of dot
in a property reference expression forming the callee in the call expression,
but dot is higher precedence as an operator than comma, and visually light, so
this seems less good.
The only lower precedence punctuator/operator that comes to mind is semicolon:
#fooo(self; arg1, arg2) {...}
but that seems like asking for trouble given ; being otherwise only a statement
terminator, modulo ASI. Consider someone using src.split(';') on existing
well-formed (perhaps from Function.prototype.toString()) source in a string
named src.
in the body of the above function, self would be bound to the implicit this
parameter of the function and this would resolve to any lexically enclosing
declarations of this or would be undefined if there were none.
That was the key point of the discussion: lexical |this|, treating it as an
identifier, to capture |this| from a closure. Exactly what people do today via
function f() {
var self = this;
return function (){... self... };
}
It isn't clear whether or not arbitrary declarations of this would be
allowed within such functions or whether this could only be bound in a
this | context.
We did not discuss allowing |this| to be bound otherwise, *except*
#foo(this = this| arg1, arg2) {...}
which did come up. One could use |self| on the left of = there, but the idea
was to support
http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values
even for the optional receiver parameter. The default parameter would be used
if the function were called via an unqualified name, e.g., f() instead of o.p().
Then Waldemar asked how one omits the receiver when calling via .apply or
.call. Obviously passing undefined is defined in ES5 strict as propagating that
value, not selecting a default parameter. This question could be answered
plausibly, I speculate (not gonna try here).
I believe that the intent of the proposal was that if you actually want to
use this to refer to the implicit parameter you would have to explicitly
declare it as:
#foo(this | arg1, arg2) {...}
and that a declaration such as
#foo( arg1, arg2) {...}
would not have a local binding for this and its implicit parameter would be
inaccessible.
... and therefore the outer |this| binding would be inherited, as is done for a
lexically scoped closure upvar.
this| Cons
It requires a new function declaration form.
The meaning of this will be different in functions declared using various
forms.
Most methods only need the inner implicit this, yet they are forced to choose
between:
function() {}
#(this|){} //net saving only 4 chars.
I wouldn't require the | there, for a small savings. The |this| reserved word
as first and only parameter name, in this case only, is enough.
Self-calls are no longer lexically explicit, you have to look at the function
header to recognize one
This is true today anyway (even ignoring host objects), for functions bound to
a particular this or self using var self=this or Function.prototype.bind.
Refactoring hazard when moving statements containing self-calls between
methods.
Same counter-argument applies here.
It is a solution that is more general than is needed to address the primary
use cases at issue.
I don't think we agree on the primary use case. If the primary use case is
lexical |this| inherited by inner (sharp-function) from outer (sharp- or
old-style) function, then #(arg1, arg2) {... this ...} suffices.
If the goal is to support OO-and-only-OO methods where |this| always has a sane
binding, even when the function is not called via o.p() but rather via f() or
f.apply(...), then the generality of not only an explicit receiver formal
parameter, but a default value for the parameter (which could be
lexically-outer |this|) is as far as I can tell necessary.
It remove the this object from the vocabulary for talking about methods.
What is the new terminology for the implicit method parameters?
This is a con?! :-P
The |this| object (with unpronounceable | brackets) is completely confusing
and a source of endless frustration. Anyway, see my first counter-con above:
var self=this and bind already make it uncertain that you always get the
receiver, even if you contrive all calls to be of the form o.p().
It may be o is the self-same bound receiver and therefore it doesn't matter,
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
JavaScript up to this point seems to have done a pretty good job of balancing
the OO and functional perspective within the language. However, I think
removing the specialness of this and the implicit this parameter may be a
step too far that breaks that balance.
I disagree with the idea that this is changing the balance. Brendan
has responded at length about the proposals, but I wasn't talking at
all about removing the distinguished first argument. For example:
function f(mythis | x, y) { ... }
is very much in the OO tradition of distinguishing the receiver --
it's just using lexical scope for disambiguation.
--
sam th
sa...@ccs.neu.edu
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
C#, CoffeeScript, and other languages use - to link a formal parameter
list to a function body, which requires bottom-up parsing in general (with
comma as operator, as JS, C++, and C have; plus Harmony's destructuring and
default parameter value proposals).
I'm not a parsing expert, but isn't destructuring just as hard to parse
top-down as = for functions would be? Given:
{ a: b, c: d } =
A top-down parser will go up to = thinking its parsing an object literal.
Then it hits the = and have to either backtrack, or just transform the
object literal AST into a destructuring pattern. Then it can proceed on its
merry way.
Wouldn't = work the same way?
(a, b) =
It parses (a, b) thinking it's a grouped comma operator (not exactly a
common expression FWIW), then it hits = realizes it's a function
parameter decl, and then either backtracks or just transforms the left-hand
AST into a param decl.
I understand this list isn't teach me the details of the JS grammar, but
it isn't obvious to me why an infix function syntax is any harder than
destructuring as far as parsing performance is concerned. Empirically, I'd
expect it to be less of an issue because the comma operator is so rare and
parameter declarations tend to be short. Is it because there are things that
would be valid in a parameter declaration that are *not* valid expressions?
- bob
Requiring bottom-up parsing has bounced off of implementors in the past,
and with JavaScriptCore switching from a Bison grammar to a top-down
hand-coded parser, I expect it will again.
I don't find syntax like this clear from a coder's POV, and there is the
re-tooling issue with highlighting editors and the ability to trivially
transform between the styles for faster adoption and old code minification
-- while these issues certainly shouldn't be deciding factors for TC39 it is
nice that leading-char lparen...rparen makes most of them go away.
That's the idea. We need to keep this simple or it will probably fall
apart, either due to ambiguities, or implementors balking at too much
complexity in parsing with more power than top-down parsers have.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
2011/3/29 Bob Nystrom rnyst...@google.com: Wouldn't = work the same way? (a, b) = It parses (a, b) thinking it's a grouped comma operator (not exactly a common expression FWIW), then it hits = realizes it's a function parameter decl, and then either backtracks or just transforms the left-hand AST into a param decl. An AST won't cut it. You have to use a parse tree because there are valid grouped comma operators containing only identifier operands that are not valid parameter lists, e.g. ((a), b) Once you do have a way to make the necessary distinctions, = is just another right associative operator that you need to pick a precedence for. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Mar 29, 2011, at 3:03 PM, Sam Tobin-Hochstadt wrote:
On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
JavaScript up to this point seems to have done a pretty good job of
balancing the OO and functional perspective within the language. However, I
think removing the specialness of this and the implicit this parameter may
be a step too far that breaks that balance.
I disagree with the idea that this is changing the balance. Brendan
has responded at length about the proposals, but I wasn't talking at
all about removing the distinguished first argument. For example:
function f(mythis | x, y) { ... }
is very much in the OO tradition of distinguishing the receiver --
it's just using lexical scope for disambiguation.
(I think you just reinforced the point I was trying to make. You prioritize
the use of lexical scoping over a single unambiguous distinguished meaning for
this)
I think what would change the balance would be not continuing to have this
serve as the implicit default for the name of the distinguished receiver. In
particular for
#f(x,y) {this.foo(x,y)}
when such definitions occurs in a method like context such as method1, method2,
and getter below:
function makeChild() {
return {
#method1() {this.method2()}, // assume # allowed as concise obj lit
method property def
#method2() {this.getter},
get #getter() {this.parent}, //implicit return
parent = this
}
}
but instead having to say
function makeChild() {
return {
#method1(this|) {this.method2()},
#method2(this|) {this.getter},
get #getter(this|) {this.parent}, //implicit return
parent = this
}
}
or
function Child(parent) {
this.method1 =#(this|) {this.method2()};
this.method2 =#(this|) {this.getter};
this.defineProperty('getter',{get:#getter(this|) {this.parent}});
this.parent = parent;
}
Optionally allowing explicit use of an alternative receiver name is probably
acceptable as long as there is a default name. The OO tradition is to
distinguish the receiver by using a fixed distinguished name, not to provide a
distinguish place for arbitrarily naming the receiver. Python and various lisp
object systems allow arbitrary receiver naming, but they have arguably never
been in the mainstream of object-oriented language design. If you take away the
special meaning of this and you don't have alternative vocabulary such as
Smalltalk does to talk about the receiver of a method then you don't have a
simple common way to talk about the object on which the method was invoked
and that is an essential concept in the OO tradition.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
2011/3/29 Mike Samuel mikesam...@gmail.com: 2011/3/29 Bob Nystrom rnyst...@google.com: Wouldn't = work the same way? (a, b) = It parses (a, b) thinking it's a grouped comma operator (not exactly a common expression FWIW), then it hits = realizes it's a function parameter decl, and then either backtracks or just transforms the left-hand AST into a param decl. An AST won't cut it. You have to use a parse tree because there are valid grouped comma operators containing only identifier operands that are not valid parameter lists, e.g. ((a), b) Once you do have a way to make the necessary distinctions, = is just another right associative operator that you need to pick a precedence for. The fact that there are parameter lists that are not valid grouped comma operators, () and (a), shouldn't cause problems. And there shouldn't be any subtle semicolon insertion bugs. bar = foo () = 4 will reliably produce a syntax error when the parameter list is stolen by a callable expression on a previous line. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Mar 29, 2011, at 3:30 PM, Bob Nystrom wrote:
C#, CoffeeScript, and other languages use - to link a formal parameter list
to a function body, which requires bottom-up parsing in general (with comma
as operator, as JS, C++, and C have; plus Harmony's destructuring and default
parameter value proposals).
I'm not a parsing expert, but isn't destructuring just as hard to parse
top-down as = for functions would be? Given:
{ a: b, c: d } =
A top-down parser will go up to = thinking its parsing an object literal.
Then it hits the = and have to either backtrack, or just transform the
object literal AST into a destructuring pattern.
That's exactly what we do in SpiderMonkey, and IIRC Rhino does the same.
My point was about parsing, not parsing + some retrospective procedure on the
AST that rewrites it. That latter is not just parsing, it's a separate pass
and not formalized in the ECMA-262 specs currently. More below.
Wouldn't = work the same way?
(a, b) =
It parses (a, b) thinking it's a grouped comma operator (not exactly a
common expression FWIW), then it hits = realizes it's a function parameter
decl, and then either backtracks or just transforms the left-hand AST into a
param decl.
It ups the ante beyond pure parsing, but yes, in the same way as
destructuring.
One example of the cost of this ante: Harmony wants early error for assignment
that would create a global variable, or use of an identifier that is not
declared via a lexical binding form. These would have to come in a later pass,
or be deferred manually till closing ) without immediately following arrow were
parsed.
There is no absolute top-down-parsing-must-be-easy requirement, and indeed
the formal grammar is LR(1), so we need to validate each edition that way --
via a bottom-up grammar and even automated checker (modulo ASI, which is
separable and treated separately).
Waldemar has shown how using only top-down parsing, however formalized, without
bottom-up grammatical validation can lead one astray:
https://mail.mozilla.org/pipermail/es-discuss/2008-October/007883.html
Something like the reverse, bottom-up validation without top-down being easy
enough, could also be a problem, since none of the major engines (AFAIK) uses
bottom-up parsing.
I understand this list isn't teach me the details of the JS grammar, but it
isn't obvious to me why an infix function syntax is any harder than
destructuring as far as parsing performance is concerned.
I agree, and I said so at https://gist.github.com/67#comments and here on
the list:
https://mail.mozilla.org/pipermail/es-discuss/2011-March/013462.html
which seems to be right before your post in the archive at
https://mail.mozilla.org/pipermail/es-discuss/2011-March/thread.html.
So yes, we can certainly consider infix-arrow, but it's more work for top-down
parser implementors than leading octothorp or equivalent prefix. Destructuring
requires similar but less work. That may not be enough to justify infix-arrow.
As usual, the big question for the future of the standard language is: do TC39
members -- in particular the parser implementors at Apple, Google, Microsoft,
Mozilla, and Opera -- all agree?
We have already approved destructuring for ES.next -- it's in the
harmony:proposals part of the wiki. But it's not the same in degree of work,
even if same in kind measured roughly.
Empirically, I'd expect it to be less of an issue because the comma operator
is so rare and parameter declarations tend to be short. Is it because there
are things that would be valid in a parameter declaration that are *not*
valid expressions?
Possibly, although if we use | to separate the optional formal receiver
parameter declaration from the positional parameters, then we're still ok: (t =
u | a, b, c) is a wacky expression: ((t = (u | a)), a, b, c) -- comma with
assignment of bitwise-or as first comma-linked operand.
Again the detailed cost analysis shows pain due to precedence shifting.
Rewriting this AST in a top-down parser to have a shape more like ((t = u), a,
b, c) or, ot label nodes functionally and with quoting elided,
formals(opt_this_formal(t, u), a, b, c), might engender some strong complaints
from implementors!
/be
- bob
Requiring bottom-up parsing has bounced off of implementors in the past, and
with JavaScriptCore switching from a Bison grammar to a top-down hand-coded
parser, I expect it will again.
I don't find syntax like this clear from a coder's POV, and there is the
re-tooling issue with highlighting editors and the ability to trivially
transform between the styles for faster adoption and old code minification
-- while these issues certainly shouldn't be deciding factors for TC39 it is
nice that leading-char lparen...rparen makes most of them go away.
That's the idea. We need to keep this simple or it will probably fall apart,
either due to ambiguities, or implementors
Re: Inner functions and outer 'this' (Re: That hash symbol)
I am really astonished to hear protection keys being thought
of as brittle under transformation: that is just the opposite
of what they are about!
Executive summary:
- de Bruijn indices are a good assembly language of
binding constructs, suitable for automatic transformation,
but not suitable for human use
- the classical name-based scheme is suitable for human
use, in principle, but is brittle under transformation
(many transformations can not be applied without
renaming); the more important these transformations
become, the less suitable this scheme is, for either
humans or machines (because of excessive renaming)
- Berkling's protection keys add flexibility to name-based
schemes, *removing* their brittleness under transformation;
it combines suitability for automated transformation
with readability for humans (in fact, both de Bruijn's
and the classical name-based scheme are special cases
of Berkling's)
The bigger issue is that scoping mechanisms in the de
Bruijn tradition are brittle for programming. They make
sense as intermediate representations or notations for
proof frameworks, because they can (sometimes) be
easier to reason about formally, but they're fragile in
the face of refactoring.
Sorry, but you have two directly conflicting statements
in one sentence there (unless I misunderstand what you
mean be fragile?): the point of de Bruijn choosing that
representation was to make automatic transformation
of scoped terms possible/easy, without breaking proofs.
That is the opposite of fragile to me.
To be fair, your suggestion is more moderate than de
Bruijn, although it's not clear whether you're proposing
the ability to refer to shadowed bindings of *all* variables
or just |this|.
Indeed, I wouldn't want to use de Bruijn indices at the
programmer level, while Berkling's protection keys enter
the frame only when naming alone isn't sufficient.
The problem is wider than 'this', 'this' just seems to be
the main use case where the problem surfaces in Javascript
practice at the moment.
With scopes and prototypes, Javascript has two separate
binding chains, but with prototypes, we can use different
prefixes, (prototype.)*.name, to skip entries in that chain.
Btw, have you ever wondered whether 'var'-bindings are
recursive?
function Outer() {
var x = outer, outer_x = x;
function Inner() {
var x = [x]; // var bindings are not recursive, are they?
log(x + ' - ' + [outer_x]);
}
Inner();
}
Outer();
Will this log '[outer] - [outer]', or '...', or something
else entirely?
I'm not making proposals yet, I'm just bringing some
useful ideas to the attention of those who have to come
up with proposals, hoping to make their work easier!-)
Seriously, the problem you're trying to solve is that |this|
is too fragile in the face of refactoring, but you're solving
it with a mechanism that's just as sensitive to refactoring.
It seems I am still not communicating Berkling's ideas
successfully (sorry about that):
his reduction systems were *based* on refactoring problem
descriptions (functional programs) to solution descriptions
(values of the functional language). His protection keys and
their handling were at the core of every scope-related
reduction/refactoring rule in those systems. If protection
keys were at all brittle in the face of refactoring, none of
his systems would ever have worked.
Quite contrary to being brittle, protection keys introduce
the necessary flexibility that allows these systems to *avoid
breaking* the binding structure while automatically rewriting
the code.
It does make it syntactically simpler to fix than
|var self = this|, but the fix is just as brittle to the
next refactoring.
Perhaps it helps to clarify the problem: when we want to
transform a program in a way that introduces new bindings
where they get in between an existing binding and some of
its bound variables (shadowing them), we have to make
additional changes to compensate (to keep the original
binding structure and program meaning intact). If that is
what you mean by brittle, there is just no way around it.
The only question is how to do the compensation. The
'var self = this' route is in the traditional line, renaming
bound variables. For non-'this' use cases, its main drawback
is that is changes the names chosen by the programmer.
If one does that during automated refactorings, the final
program is sometimes not recognizable to the programmer
who wrote the initial code (the alternative is for the
refactoring tool to balk and ask the programmer to resolve
the naming conflict before invoking the refactoring again).
For 'this', the issue is the other way round: the name is
not the programmer's choice, the binders for 'this' are
implicit (so we cannot rename at the binder), and one
cannot rename the variable without losing its special
functionality (so we end up with two names
Re: Inner functions and outer 'this' (Re: That hash symbol)
I am really astonished to hear protection keys being thought of as brittle under transformation: that is just the opposite of what they are about! Sorry to astonish you. :) Executive summary: - de Bruijn indices are a good assembly language of binding constructs, suitable for automatic transformation, but not suitable for human use - the classical name-based scheme is suitable for human use, in principle, but is brittle under transformation(many transformations can not be applied withoutrenaming); the more important these transformations become, the less suitable this scheme is, for either humans or machines (because of excessive renaming) - Berkling's protection keys add flexibility to name-basedschemes, *removing* their brittleness under transformation; it combines suitability for automated transformation with readability for humans (in fact, both de Bruijn'sand the classical name-based scheme are special casesof Berkling's) Well, you're just asserting that Berkling's keys remove their brittleness without evidence. And I'm afraid I've seen enough evidence in my experience to make me doubt your claim. Just take a look at what happens to the definition of alpha-conversion in a language with Berkling's keys. Traditionally, when you alpha-convert a binding x, you can stop the induction whenever you hit an inner binding (shadowing) of x. Not so with your proposal: now you have to keep going -- and decrement an accumulator argument to the algorithm (not exactly obvious!) -- to look for outer references within the inner binding. What does this mean in practice? It means that someone refactoring at an outer level may be unaware that they've affected the index of an inner reference by changing a binding. It means you lose some of the locality that you get with traditional lexical scope. The bigger issue is that scoping mechanisms in the de Bruijn tradition are brittle for programming. They make sense as intermediate representations or notations for proof frameworks, because they can (sometimes) be easier to reason about formally, but they're fragile in the face of refactoring. Sorry, but you have two directly conflicting statements in one sentence there (unless I misunderstand what you mean be fragile?): the point of de Bruijn choosing that representation was to make automatic transformation of scoped terms possible/easy, without breaking proofs. That is the opposite of fragile to me. No contradiction. A machine is much better at consistently shifting big collections of integer indices without making a mistake. As you acknowledged, de Bruijn notation is not fit for humans. The problem is wider than 'this', 'this' just seems to be the main use case where the problem surfaces in Javascript practice at the moment. And the reason for this is that |this| is implicitly bound. Which, as I said in my last email, is a good motivation for considering making it possible explicitly bind |this|. IOW, there are other solutions than the one you describe that address the problem. And I believe your solution is worse than the problem. With scopes and prototypes, Javascript has two separate binding chains, but with prototypes, we can use different prefixes, (prototype.)*.name, to skip entries in that chain. Prototype chains and lexical environments are two totally different semantic constructs -- only one is used for scope. They shouldn't be confused. Btw, have you ever wondered whether 'var'-bindings are recursive? This is a really basic question about JS, and not appropriate for this list. Seriously, the problem you're trying to solve is that |this| is too fragile in the face of refactoring, but you're solving it with a mechanism that's just as sensitive to refactoring. It seems I am still not communicating Berkling's ideas successfully (sorry about that): No, I understand the semantics you describe. I think you just haven't understood what I'm saying. I'm not talking about automatic rewriting. All of these representations of binding structure (names, de Bruijn indices, the locally nameless approach, the Berkling representation you describe) are different ways of representing graphs as trees. For the sake of formal systems, they're all equally expressive. The problem is that some of them are more susceptible to human error than others. If you spend time working with tree manipulation languages like XPath, you find that being able to refer to parent links makes your program sensitive to fine-grained changes in the tree structure, which means that refactoring is more likely to end up making mistakes. If protection keys were at all brittle in the face of refactoring, none of his systems would ever have worked. Nonsense-- there are all sorts of technologies that work and are brittle. Ask me over a beer some time, and I'll name a few. ;)
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Mar 27, 2011, at 11:13 AM, David Herman wrote:
To be fair, your suggestion is more moderate than de Bruijn, although it's
not clear whether you're proposing the ability to refer to shadowed bindings
of *all* variables or just |this|. If it's the former, I'm *strongly*
opposed. If it's the latter, well, I guess I'm still pretty opposed, just
maybe less strongly. :)
Dave, I think that applying this solution to the this-scoping issue may be a
really good idea
Claus, thanks from bringing a new (old) idea into the discussion.
I agree with Dave about all the fragility issues he mentioned for the general
case. Also, I just don't see the general problem (if it is even a problem)
as one that is important enough to try to fix in the language since it is
probably rare and it can be avoided by careful naming.
However, the specific case of 'this' is a different matter.'this' is
implicitly rebound in every function scope and the JavaScript programmer has no
direct control over the naming and shadowing. The result is that they have to
know and use the self renaming pattern.
This issue shows up enough in defining objects via object literal methods and
in methods that call higher order functions that it is something that may well
be worth addressing in the language. Particularly as we discuss adding
additional declarative forms to Harmony that included nested method
definitions. The outer 'this' problem is limited enough that we can avoid
things like dynamic scoping complications in the solution. Also it is limited
enough that I don't believe that the solution imposes refactoring
complications.
Here is a sketch of a proposal:
^this is added as a new lexical token of the language. When spoken it is
pronounced as outer this . In the expression grammar ^this is a primary
expression.
It is a syntax error for ^this to appear outside of a function body. It may
not occur at the top level of a program.
When evaluated, the value of ^this is the this binding of the function that
immediately lexically encloses the function body that contains the ^this. It
is a early syntax error if there is no such function. For example:
//at the top level
var self = ^this; //syntax error, at the top level
function foo() {
^this.bar(); //syntax error, no enclosing function
}
The two primary use cases for ^this are exemplified by the following two
examples:
MyObj.prototype.addClickHandingForElement(elem) {
elem.addEventListener('click', function (e) {^this.handleClick(this,e)});
}
MyObj.prototype.wrap = function () {
// create a wrapper object that limits access to the properties of one of my
objects
return {
name: this.id, //fix name of wrapper at creation (uses this of wrap
call
get foo () {return ^this.foo}, //outer this is this of wrap call
set bar(val) {^this.bar = val} //outer this is this of wrap call
}
Note that only one level outer this access is supported, ^^this would be a
syntax error. In the rare cases where somebody really needs deeper access to
shadowed this binding then they can fall back to the self pattern.
I see minimal refactoring hazards here as the outer scope reference is limited
to one level, is explicitly marked at the usage site, and only applies to this.
Possible reservations:
This use of ^ probably would preclude its use as a short form of the 'return'
keyword (for those people who aren't in favor of adding implicit returns).
It looks odd to old Smalltalk programmers.
Overall, I really like ^this as a narrow solution to a specific real usage
problem. I'm interested in reactions and unless somebody thinks of something
that seriously torpedoes it I will probably write it up as a strawman.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Mon, Mar 28, 2011 at 10:35, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Overall, I really like ^this as a narrow solution to a specific real usage problem. I'm interested in reactions and unless somebody thinks of something that seriously torpedoes it I will probably write it up as a strawman. I like ^this. We (Chromium/V8) discussed introducing 'self' as a a way to get the lexically bound 'this'. The main issue we could think of was that it might be hard for users to know when to use '^this' vs when to use 'this'. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Mon, Mar 28, 2011 at 10:16 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: On Mon, Mar 28, 2011 at 10:35, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Overall, I really like ^this as a narrow solution to a specific real usage problem. I'm interested in reactions and unless somebody thinks of something that seriously torpedoes it I will probably write it up as a strawman. I like ^this. We (Chromium/V8) discussed introducing 'self' as a a way to get the lexically bound 'this'. The main issue we could think of was that it might be hard for users to know when to use '^this' vs when to use 'this'. There seem to be a bunch of different but related suggestions here, some of which seem more useful than others: 1. |^this| as a new special token that always refers to the lexical meaning of |this|. 2. |^this| as a new special way to get the version of |this| bound in the next outer scope. I believe that this is sometimes different from 1 (maybe just at the top level). 3. ^ as a general way to move out a scope, but restricted to |this| 4. ^ as a general way to refer up the scope chain, for any identifier including |this|. Personally, I think that a way to name the implicit binding of the receiver would be better than adding more hardcoded names to the standard. The |^this| proposals seem problematically implicit, especially since we had quite reasonable suggestions (at the meeting at least) for naming |this| explicitly instead. -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On Mar 28, 2011, at 8:30 PM, Sam Tobin-Hochstadt wrote: On Mon, Mar 28, 2011 at 10:16 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: On Mon, Mar 28, 2011 at 10:35, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Overall, I really like ^this as a narrow solution to a specific real usage problem. I'm interested in reactions and unless somebody thinks of something that seriously torpedoes it I will probably write it up as a strawman. I like ^this. We (Chromium/V8) discussed introducing 'self' as a a way to get the lexically bound 'this'. The main issue we could think of was that it might be hard for users to know when to use '^this' vs when to use 'this'. There seem to be a bunch of different but related suggestions here, some of which seem more useful than others: 1. |^this| as a new special token that always refers to the lexical meaning of |this|. not in my proposal 2. |^this| as a new special way to get the version of |this| bound in the next outer scope. I believe that this is sometimes different from 1 (maybe just at the top level). almost, but not quite what I am proposing. ^this refers to the this binding of the function that lexically encloses the containing function. this remains a reserved identifier and is not rebindable by block level declarations. ^this is illegal at the top level or directly in the direct body of a top level function because in nether case is there a useful outer this value to reference. 3. ^ as a general way to move out a scope, but restricted to |this| not in my proposal 4. ^ as a general way to refer up the scope chain, for any identifier including |this|. not in my proposal. (I think I'm the only one to use the syntax ^this in a proposal so I'm not sure where 1,3,4 (at least using ^this syntax) came from. Personally, I think that a way to name the implicit binding of the receiver would be better than adding more hardcoded names to the standard. The |^this| proposals seem problematically implicit, especially since we had quite reasonable suggestions (at the meeting at least) for naming |this| explicitly instead. The reason I really like ^this is it co-exists very nicely with the existing fixed implicit this binding. It address the primary scoping issue that arises from that implicit binding. Unlike the explicit this naming forms that have been discussed it would work in all function definition forms without adding any new header syntax to any of the function definition forms. Allen -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
function f() {} // target this binding
(function () {
function f() { // skip this binding
The line directly above introduces two bindings in two scopes. Did
you mean that both of them are skipped, or just one?
This made me feel as if I was missing something, so I went back to the
ES spec: by my reading of '13. Function Definition', a FunctionDeclaration
for 'f' introduces a binding for 'f' into the scope in which the declaration
occurs (in this case, the body of the immediately executed anonymous
function). That is _one_ binding.
If we had a named FunctionExpression 'f' instead, that would introduce
a binding for 'f' in 'f's body. That would still be _one_ binding.
Since 'f's body is nested in that of the anonymous function, any
binding in scope in the outer function's body is also in scope in 'f's
body, as long as it isn't shadowed by a more local binding.
Not usually (did your counting scopes cloud the idea, or
am I missing some Javascript-specific problem?) - it has
I have never used such a feature, and thanks for recounting your
experiences below.
Ok, sorry. It is easy to forget for me that this idea is new to
most programmers. Fortunately, in that case, just playing around
with the idea will help. I just want to make sure that this isn't
hampered by miscommunications.
Counting scopes seems brittle to me because changes to
intervening scopes can break code that is distant from them.
That's, of course, always the case with introducing a variable
that may mask.
Indeed, the problem of shadowing is always there. When one
starts rewriting/refactoring programs, that problem becomes
more prominent, because one needs to avoid variable capture.
And when one starts reasoning about program rewriting, the
problem is so central that is needs a solution.
De Bruijn went with abandoning all names, which only works
at implementation-level (and presenting users a named form
re-introduces the problem); others went with conventions that
work only at proof-level (where pesky, but well-understood
details can be abstracted away); most went with forcing
renaming of bound variables, but this really messes with
the programmer-chosen names.
The latter is the issue Javascript programmers are running
into with the fixed special name 'this' (with manual renaming
a la 'var that = this', to avoid shadowing).
Berkling's approach was the first that introduced a systematic
way of handling binding structure and preventing name
capture _without_ interfering with programmer-chosen
names. I wouldn't expect Javascript code to use more than
'#this' or '##this', but since such expectations never outlive
practice, it is good if the system can handle whatever
programmers actually do.
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich bren...@mozilla.com wrote:
This es-discuss group sounds exactly like that ES Tech group -- why make
a new one?
I've always considered this group to be about super-fine nit-picky points of
ES, clarifications about recent changes, and well-thought out standards
proposals. My thought in proposing ES Tech was that there is probably
room for something with a slightly more casual tone, where ideas could be
bounced off people as part of the formation process, and less advanced
questions could be asked and answered. But not full of spam.
If there's too much noise in any group, new or old, the group becomes
useless. Asking for some simple ambiguity checks before posting syntax
strawmen, and pleading to avoid one-line followups that overcite, etc. is
*not* wrath. It's part of the well-known netiquette standard, but not
enforced much these days.
True that. Turning back my own mental clock, I remember getting flamed once
for posting untested code in ... comp.unix.programmer? The flamer was
right, and I didn't do it again, but I kept participating.
And to be fair, the JS grammar is subtle enough that it's fine to propose
somehting that *might* work, only to have grammarians debug it.
Non leading-char solutions have the disadvantage of using some other kind
of bracketing -- e.g. `a,b { return a + b; }`
This is ambiguous too. A comma expression followed by a block (if in an
outer function, the return is legal).
Not that this was a serious proposal -- but am I missing something, or did
you miss the trailing back-tick in my example? Specifically, I don't think
this is ambiguous:
FunctionExpression :
function Identifieropt ( FormalParameterListopt ) { FunctionBody }
or
`Identifieropt FormalParameterListopt { FunctionBody }`
..although my native thought pattern is definitely LALR(1). I find LL(k)
ambiguities hard to spot, not having worked with a top-down parser-generator
since I was in school! Argh, now I'm not sure if that grammar is
unambiguous for small k due to nested FunctionExpressions. I don't think
there is a comma-expression hazard there, though.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
2011/3/26 Jeff Walden jwalden...@mit.edu: Further, how would this interact with eval introducing (or in some systems even removing) lexical bindings? (Or maybe eval doesn't matter if this only If, as at https://mail.mozilla.org/pipermail/es-discuss/2011-February/012896.html , harmony is based on ES5 strict, eval cannot add or remove new lexical bindings. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
2011/3/27 Wes Garland w...@page.ca:
On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich bren...@mozilla.com wrote:
FunctionExpression :
function Identifieropt ( FormalParameterListopt ) { FunctionBody }
or
`Identifieropt FormalParameterListopt { FunctionBody }`
..although my native thought pattern is definitely LALR(1). I find LL(k)
ambiguities hard to spot, not having worked with a top-down parser-generator
since I was in school! Argh, now I'm not sure if that grammar is
unambiguous for small k due to nested FunctionExpressions. I don't think
there is a comma-expression hazard there, though.
The need to balance the curly brackets in the body makes it
unambiguous for nested function expressions. You don't need to look
ahead to tell whether a back-tick is an opening or closing back-tick,
just remember whether the last-non-comment-non-whitespace token was a
close curly that closed a function expression's body.
It is ambiguous with
http://wiki.ecmascript.org/doku.php?id=strawman:quasis#syntax_normative
if quasi type tags are optional.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
Further, how would this interact with eval introducing (or in
some systems even removing) lexical bindings?
Disclaimer 1: the Berkling-style systems I'm familiar with did
not support eval, so I cannot argue from experience here
Disclaimer 2: the reason for this was that unlimited reflection
support breaks all equational theories about programs
(eg toString can distinguish otherwise semantically
equivalent programs, so only identical programs can be
considered equal if reflection is taken into account) and
equational reasoning was core to reduction languages
Eval already breaks lexical scoping, so there is little hope of
it having no interactions with extensions of lexical scoping.
One might limit eval('code') not to have any effect on
the context's lexical scope chain, but that would indeed
limit eval's functionality (the eternal conflict between
expressiveness and reasoning). Limiting eval/toString
to be unaffected by the context's local scope chain would
also be possible, but again, that would mean changing
a lot of code.
Since all that an implementation or programmer has to
go with in the presence of eval is the lexical scope chain
at any point of execution, adding protection is probably
not going to make matters worse wrt eval. Similarly,
toString can already distinguish between codes that
differ only by renaming.
Is that sufficiently vague / reassuring?-)
Nevertheless this 35-year-old idea seems fresh in the
context of ECMAScript development, and worth
thinking about, so thanks for bringing it up.
Always happy to promote a good idea!-)
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
The questions about eval look mostly unproblematic to me. In ES5-strict and
Harmony, eval is unable to modify its caller's scope. In legacy mode, I imagine
the semantics would be pretty straightforward, if problematic; but eval being
able to affect its caller's scope is problematic anyway, so it doesn't really
bother me.
The bigger issue is that scoping mechanisms in the de Bruijn tradition are
brittle for programming. They make sense as intermediate representations or
notations for proof frameworks, because they can (sometimes) be easier to
reason about formally, but they're fragile in the face of refactoring.
To be fair, your suggestion is more moderate than de Bruijn, although it's not
clear whether you're proposing the ability to refer to shadowed bindings of
*all* variables or just |this|. If it's the former, I'm *strongly* opposed. If
it's the latter, well, I guess I'm still pretty opposed, just maybe less
strongly. :)
Seriously, the problem you're trying to solve is that |this| is too fragile in
the face of refactoring, but you're solving it with a mechanism that's just as
sensitive to refactoring. It does make it syntactically simpler to fix than
|var self = this|, but the fix is just as brittle to the next refactoring. And
people already know how to use |var self = this|, so this would just introduce
one more programming pattern you have to teach people for dealing with
|this|-capture, but a less robust pattern than the one they already have.
But more broadly, my problem with this suggestion is that it's too drastic a
semantic change for the specific problem it's addressing. I much prefer the
space we've been exploring that allows for explicit binding of `this'. It's
more robust and less disruptive a change to lexical scoping.
Dave
On Mar 27, 2011, at 9:39 AM, Claus Reinke wrote:
Further, how would this interact with eval introducing (or in some systems
even removing) lexical bindings?
Disclaimer 1: the Berkling-style systems I'm familiar with didnot support
eval, so I cannot argue from experience here
Disclaimer 2: the reason for this was that unlimited reflection
support breaks all equational theories about programs
(eg toString can distinguish otherwise semantically
equivalent programs, so only identical programs can be
considered equal if reflection is taken into account) and
equational reasoning was core to reduction languages
Eval already breaks lexical scoping, so there is little hope of it having no
interactions with extensions of lexical scoping.
One might limit eval('code') not to have any effect on
the context's lexical scope chain, but that would indeed
limit eval's functionality (the eternal conflict between
expressiveness and reasoning). Limiting eval/toString
to be unaffected by the context's local scope chain would
also be possible, but again, that would mean changing
a lot of code.
Since all that an implementation or programmer has to go with in the presence
of eval is the lexical scope chain at any point of execution, adding
protection is probably not going to make matters worse wrt eval. Similarly,
toString can already distinguish between codes that
differ only by renaming.
Is that sufficiently vague / reassuring?-)
Nevertheless this 35-year-old idea seems fresh in the context of ECMAScript
development, and worth thinking about, so thanks for bringing it up.
Always happy to promote a good idea!-)
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
As covered with Jeff Walden, I misread your `` usage as meta not concrete. And
those quote characters are wanted for quasis, and anyway not function-y in any
language I know of. Mike Samuel's latest shows they aren't strictly necessary.
Rather than sketch what might look pretty or easy to type and see if it can be
made to parse, we could do better by considering nearby languages. In the
https://gist.github.com/67#comments I ask whether we skirt the bottom-up
parsing cliff one more time, and consider
- {/* no formals */}
()- {/* no formals */}
a - {/* one formal */}
(a,b) - {/* two formals */}
([d,e],f) - {/* two formals, first destructures via array pattern */}
These are not all necessary. CoffeeScript supports the first, C# the third,
IIRC. The body could be an expression in parentheses (if not of high
precedence). Details TBD. But this would get away from the pick a funny prefix
punctuator or symbol game.
The parsing may be something we can finesse in a top-down parser, by parsing
the covering RHS equivalent and then walking the AST to validate that it is a
well-formed parameter list.
In no case is anything like quoting required, or IMHO a good idea.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where end users (engineers and
architects as well as scripters) could contribute to the developer experience
of using JavaScript without incurring the wrath
wrath? I may have failed to add a smiley, but c'mon. No wrath here.
of it's fathers, which appear to be more focused on the interpreter of the
language rather than the thrust of it's use cases (which almost always appear
to bottom out on library abstractions to solve the issues).
What do you mean? What library abstractions, and what issues? Please be
specific.
Remember, I'm the one pushing for new syntax more than many others involved in
TC39:
http://brendaneich.com/2011/01/harmony-of-my-dreams/
I really would have hoped that rather than assuming an asses POV that this
list would assume the best without requirement of over-qualification.
Skipping, I don't know how to read this and I really don't want to guess
(asses POV meaning ass's POV? Who said anything about ass here? Yeesh.)
Like it or not, JavaScript is the glue of the web. This language space has
been embroiled in vendor politics
There is no vendor politics in this thread, though.
since day one- end users need an effective forum to describe their
requirements- that is what I was espousing. Clear enough?
No, you have not made any requirement clear. Let's take your first post today:
Implicit functions?
globalMethod(argument)
{
// implementation
};
AnObject.prototype.method(value)
{
// whatevs
};
Dropping function as the leading keyword makes these examples ambiguous, due to
automatic semicolon insertion as Mike Samuel pointed out.
Sure, losing the heaviness of eight-letter 'function' is a goal, and we've
discussed it often:
http://www.google.com/search?q=site%3Amail.mozilla.org+shorter+function+syntax
The ecmascript.org wiki has a strawman on it:
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
This is not going forward as-is, and the plan is to write a new strawman, but
the goal of shorter function syntax is getting attention.
We spent time yesterday at the TC39 meeting not only on shorter syntax but
exactly how to support better |this| handling for several distinct use-cases:
inner functions that want the outer |this|, callbacks that want a certain
|this|, and object methods that want the receiver when called as methods of a
given (receiver) object (else possibly a default such as the outer function's
|this|).
Anyway, there's more to do than fix syntax, but the syntax has to be
unambiguous. That's the first requirement, before we can go further.
Kevin Smith started this thread by objecting to #, and that's fair. It's a bit
chicken-scratchy. If we can find a better introductory keyword or formal
parameter bracketing form, I'm game. I don't think -bracketing is it, not
only due to E4X (who cares, right?) but mainly because that breaks symmetry
with call expression, which uses ()-bracketing.
CoffeeScript uses () for formal parameter bracketing (where there are formal
parameters; parameter-less functions start with - or =), but allows call
expressions to elide the ( and ) where there is no ambiguity -- no ambiguity
according to CoffeeScript's complex, evolving rules for disambiguation.
I had the chance to talk to Jeremy Ashkenas about this recently, and he does
not recommend trying to graft these rules onto JS and standardize them. I agree.
So a leading character instead of 'function' still seems like the cleanest
solution. Ideas other characters than '#' are welcome, since so long as they
are not used in the language already (either as punctuators, operators, or
identifier characters), they can't introduce ambiguity.
You do yourself a disservice by assuming idiocracy.
I did not assume anything.
(Good movie, though -- Mike Judge is great!)
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Inner functions and outer 'this' (Re: That hash symbol)
We spent time yesterday at the TC39 meeting not only on shorter
syntax but exactly how to support better |this| handling for several
distinct use-cases: inner functions that want the outer |this|,
callbacks that want a certain |this|, and object methods that
want the receiver when called as methods of a given (receiver)
object (else possibly a default such as the outer function's |this|).
That reminds me of an old solution looking for this problem.
Back in 1976, Klaus Berkling suggested to complement the
lambda calculus with an operator to protect variables from
the nearest enclosing binding [1].
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection key skips one level of binding, lexically).
If I may use '#' as a placeholder for a suitable protection
key, then this translates to Javascript as
function Outer() {
var x = outer;
function Inner() {
var x = inner;
log(x); // inner
log(#x); // outer
log(##x); // global scope, probably unbound
}
}
I've seen this in action in a functional language based on his
ideas, in the late 80s, and have since been repeatedly surprised
by general unawareness of Berkling's ideas. Variants have been
rediscovered occasionally - git's HEAD^ is a recent example:
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
Of course, applying the idea to Javascript's 'this' is complicated
by dynamic scoping. Personally, I've found it useful to think of
'this' as an implicit, lexically scoped parameter - then I only have
to worry about which applications pass which implicit parameter.
I don't know whether that is sufficient to make Berkling's idea
applicable here, but I wanted to make sure it is known;-)
Claus
http://www.haskellers.com/user/claus
[1] The original report is hard to come by, the idea was also
published again in 1982, items 5/6 in this bibliography:
http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/b/Berkling:Klaus_J=.html
Here is the original report's abstract:
@techreport{Berkling76,
author = {Berkling, K.J.},
title = {{A Symmetric Complement to the Lambda Calculus}},
institution = GMD,
note= {ISF-76-7},
month = {September},
year= 1976,
abstract = {The calculi of Lambda-conversion introduced by A.Church
are complemented by a new operator lambda-bar, which is in
some sense the inverse to the lambda-operator. The main
advantage of the complemented system is that variables do
not have to be renamed. Conversely, any renaming of
variables in a formula is possible. Variables may, however,
appear with varied numbers of lambda-bars in front of them.
Implementations of the lambda calculus representation with
the symmetric complement are greatly facilitated.
In particular, a renaming of all variables in a formula to
the same one is possible. Variables are then distinguished
only by the number of preceding lambda-bars. Finally, we
give a four symbol representation of the lambda calculus
based on the above mentioned freedom in renaming. },
topics = {FP - Lambda Calculi}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
end users (engineers and architects as well as scripters) could contribute
to the developer experience of using JavaScript
I was going to suggest comp.lang.javascript, but I just had a look and it
seems to have been taken over by DOM questions and spam. David, why don't
you start an ES Tech group or something, and ban questions which aren't
related to JS? (Copy your charter from comp.lang.c, maybe). Announce it
here, and I will subscribe. Probably even participate.
Kevin Smith started this thread by objecting to #, and that's fair. It's a
bit chicken-scratchy. If we can find a better introductory keyword or formal
parameter bracketing form, I'm game.
I like Doug's florin idea from an aesthetic POV, but I have two problems
with it -- suddenly, I have to care what charset my editor is using -- but
more importantly, I can't figure out how to type it on my Sun keyboard or on
my Windows box. Also, what of JS which is delivered on the web using
something other than unicode?
Allowing both is an interesting option, but then I remember how annoying
ANSI tri-graphs were (history lesson for !brendan: not all terminals had {,
C programs allow ?? instead) and realise that would be a mistake.
I, too, find #(a,b) but frankly, there aren't many lead-char solutions which
aren't ugly, easy to type, and not used by identifiers (or as operators)
already. What have we got to chose from? I think `@#%^* -- none of these
are measurably better than # and some are worse. Maybe you could make the
point that looks like a melted lambda. But I see no point in bike shedding
over this.
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. `a,b { return a + b; }` -- I don't find syntax like this
clear from a coder's POV, and there is the re-tooling issue with
highlighting editors and the ability to trivially transform between the
styles for faster adoption and old code minification -- while these issues
certainly shouldn't be deciding factors for TC39 it is nice that
leading-char lparen...rparen makes most of them go away.
You do yourself a disservice by assuming idiocracy.
I don't think Brendan ever assumed that this place is governed by idiots.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Mar 26, 2011, at 6:44 AM, Wes Garland wrote:
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
end users (engineers and architects as well as scripters) could contribute
to the developer experience of using JavaScript
I was going to suggest comp.lang.javascript, but I just had a look and it
seems to have been taken over by DOM questions and spam. David, why don't
you start an ES Tech group or something, and ban questions which aren't
related to JS? (Copy your charter from comp.lang.c, maybe). Announce it
here, and I will subscribe. Probably even participate.
Kevin Smith started this thread by objecting to #, and that's fair. It's a
bit chicken-scratchy. If we can find a better introductory keyword or formal
parameter bracketing form, I'm game.
I like Doug's florin idea from an aesthetic POV, but I have two problems
with it -- suddenly, I have to care what charset my editor is using -- but
more importantly, I can't figure out how to type it on my Sun keyboard or on
my Windows box. Also, what of JS which is delivered on the web using
something other than unicode?
Allowing both is an interesting option, but then I remember how annoying
ANSI tri-graphs were (history lesson for !brendan: not all terminals had {,
C programs allow ?? instead) and realise that would be a mistake.
I, too, find #(a,b) but frankly, there aren't many lead-char solutions which
aren't ugly, easy to type, and not used by identifiers (or as operators)
already. What have we got to chose from? I think `@#%^* -- none of these
are measurably better than # and some are worse. Maybe you could make the
point that looks like a melted lambda. But I see no point in bike shedding
over this.
Erik and I worked through most of these options, considering their placement on
US and non-US keyboard layouts and their relative does it look like a
function?-ness. # won, not because either of us loved it, but because it was
the least bad.
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. `a,b { return a + b; }` -- I don't find syntax like this
clear from a coder's POV, and there is the re-tooling issue with
highlighting editors and the ability to trivially transform between the
styles for faster adoption and old code minification -- while these issues
certainly shouldn't be deciding factors for TC39 it is nice that
leading-char lparen...rparen makes most of them go away.
You do yourself a disservice by assuming idiocracy.
I don't think Brendan ever assumed that this place is governed by idiots.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
slightly...@google.com
slightly...@chromium.org
a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
2011/3/26 Wes Garland w...@page.ca:
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
end users (engineers and architects as well as scripters) could contribute
to the developer experience of using JavaScript
I was going to suggest comp.lang.javascript, but I just had a look and it
seems to have been taken over by DOM questions and spam. David, why don't
you start an ES Tech group or something, and ban questions which aren't
related to JS? (Copy your charter from comp.lang.c, maybe). Announce it
here, and I will subscribe. Probably even participate.
I'd be happy to participate too.
If the goal is to, as Kevin suggested, provide an early vetting
service of ideas as to how the language *should be* by people who know
have a detailed knowledge of how the language *is*, would a ticket
system be more appropriate/additionally useful? A ticket system might
use scarce attention better since it is 1:1, not 1:n.
Kevin Smith started this thread by objecting to #, and that's fair. It's a
bit chicken-scratchy. If we can find a better introductory keyword or formal
parameter bracketing form, I'm game.
I like Doug's florin idea from an aesthetic POV, but I have two problems
with it -- suddenly, I have to care what charset my editor is using -- but
more importantly, I can't figure out how to type it on my Sun keyboard or on
my Windows box. Also, what of JS which is delivered on the web using
something other than unicode?
Allowing both is an interesting option, but then I remember how annoying
ANSI tri-graphs were (history lesson for !brendan: not all terminals had {,
C programs allow ?? instead) and realise that would be a mistake.
I, too, find #(a,b) but frankly, there aren't many lead-char solutions which
aren't ugly, easy to type, and not used by identifiers (or as operators)
already. What have we got to chose from? I think `@#%^* -- none of these
are measurably better than # and some are worse. Maybe you could make the
point that looks like a melted lambda. But I see no point in bike shedding
over this.
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. `a,b { return a + b; }` -- I don't find syntax like this
clear from a coder's POV, and there is the re-tooling issue with
highlighting editors and the ability to trivially transform between the
styles for faster adoption and old code minification -- while these issues
certainly shouldn't be deciding factors for TC39 it is nice that
leading-char lparen...rparen makes most of them go away.
You do yourself a disservice by assuming idiocracy.
I don't think Brendan ever assumed that this place is governed by idiots.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
2011/3/26 Claus Reinke claus.rei...@talk21.com:
We spent time yesterday at the TC39 meeting not only on shorter
syntax but exactly how to support better |this| handling for several
distinct use-cases: inner functions that want the outer |this|,
callbacks that want a certain |this|, and object methods that
want the receiver when called as methods of a given (receiver)
object (else possibly a default such as the outer function's |this|).
That reminds me of an old solution looking for this problem.
Back in 1976, Klaus Berkling suggested to complement the
lambda calculus with an operator to protect variables from
the nearest enclosing binding [1].
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection key skips one level of binding, lexically).
If I may use '#' as a placeholder for a suitable protection
key, then this translates to Javascript as
function Outer() {
var x = outer;
function Inner() {
var x = inner;
log(x); // inner
log(#x); // outer
log(##x); // global scope, probably unbound
}
}
To clarify, if I have the code
foo(#x)
and suddenly I realize that I need a to guard it with a condition,
if (bar) {
foo(#x)
}
this would ?not? change the binding of #x since, although I have
introduced a new let scoped block, x is not declared in that scope so
it is not counted against the stack of #'s.
It is not always easy to count scopes though without knowing a lot of
details. E.g. changing
function f() {}
(function () {
function () {
return f;
}
})()
requires two hashes
function f() {}
(function () {
function f() {
return ##f;
}
})()
since f was introduced both into the body scope, and into the outer
scope via the function declaration.
It seems brittle, and it seems that overloading labels to name scopes
would provide a less brittle alternative if this really is desired.
myScopeName: {
let x;
function f(x) {
g(x + myScopeName.x);
}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection key skips one level of binding, lexically).
To clarify, if I have the code
foo(#x)
and suddenly I realize that I need a to guard it with a condition,
if (bar) {
foo(#x)
}
this would ?not? change the binding of #x since, although I have
introduced a new let scoped block, x is not declared in that scope so
it is not counted against the stack of #'s.
This would _not_ change the binding of #x, because it
does not introduce or remove any bindings for x. Both
bindings and protections are specific to variable names.
It is not always easy to count scopes though without knowing
a lot of details. E.g. changing
function f() {}
(function () {
function () {
return f;
}
})()
requires two hashes
function f() {}
(function () {
function f() {
return ##f;
}
})()
since f was introduced both into the body scope, and into
the outer scope via the function declaration.
The counting is (usually) just by enclosing binders, not by how
many constructs or nested scopes they affect. So, I would count
one intervening binding here, and one protection # to keep the
binding structure as before:
function f() {} // target this binding
(function () {
function f() { // skip this binding
return #f;
}
})()
We could have this instead, where there'd be two bindings
for f to skip, and two protections to keep the binding structure
intact:
function f() {} // target this binding
(function () {
var f = function f() { // skip these bindings
return ##f;
}
})()
It seems brittle,
Not usually (did your counting scopes cloud the idea, or
am I missing some Javascript-specific problem?) - it has
been the basis of soft- and hardware implementations
of functional (and functional-logic) languages.
If we can find the binding for an unprotected variable, we
can find the binding to skip for a protected variable; one
binding and one protection cancel each other; once an
unprotected variable has a binding, it is bound.
It is still just the usual lexical scoping in action - the only
change is that shadowed bindings can now be reached,
by protecting variables from shadowing bindings.
That is all one needs to know about the system at the
programmer-level, at least for a language like Javascript,
whose operational semantics isn't defined by rewrite
rules (*).
Hope this helps,
Claus
(*) As a student, I found programming with it very intuitive,
even though the language we were given did execute by
rewriting (so the protection keys adjusted to dynamically
changing program structure, e.g, when a function definition
was inlined at a call site);
implementers find it similar to deBruijn-Indices (if an
implementation renames all variables to be the same,
the resulting protection keys correspond directly to
indices for stack access), but those are not usually
palatable to programmers;
http://en.wikipedia.org/wiki/De_Bruijn_index
when reasoning about programs, or rewriting programs,
it means that names are less of a problem, because we
can always preserve the binding structure (no more
exceptions like you can wrap code in a function,
provided the code does not mention the function
name or parameters).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
2011/3/26 Claus Reinke claus.rei...@talk21.com:
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection key skips one level of binding, lexically).
To clarify, if I have the code
foo(#x)
and suddenly I realize that I need a to guard it with a condition,
if (bar) {
foo(#x)
}
this would ?not? change the binding of #x since, although I have
introduced a new let scoped block, x is not declared in that scope so
it is not counted against the stack of #'s.
This would _not_ change the binding of #x, because it
does not introduce or remove any bindings for x. Both bindings and
protections are specific to variable names.
It is not always easy to count scopes though without knowing a lot of
details. E.g. changing
function f() {}
(function () {
function () {
return f;
}
})()
requires two hashes
function f() {}
(function () {
function f() {
return ##f;
}
})()
since f was introduced both into the body scope, and into the outer scope
via the function declaration.
The counting is (usually) just by enclosing binders, not by how many
constructs or nested scopes they affect. So, I would count one intervening
binding here, and one protection # to keep the binding structure as before:
function f() {} // target this binding
(function () {
function f() { // skip this binding
The line directly above introduces two bindings in two scopes. Did
you mean that both of them are skipped, or just one?
return #f;
}
})()
We could have this instead, where there'd be two bindings
for f to skip, and two protections to keep the binding structure
intact:
function f() {} // target this binding
(function () {
var f = function f() { // skip these bindings
return ##f;
}
})()
It seems brittle,
Not usually (did your counting scopes cloud the idea, or
am I missing some Javascript-specific problem?) - it has
I have never used such a feature, and thanks for recounting your
experiences below. Counting scopes seems brittle to me because
changes to intervening scopes can break code that is distant from
them. That's, of course, always the case with introducing a variable
that may mask.
been the basis of soft- and hardware implementations
of functional (and functional-logic) languages.
If we can find the binding for an unprotected variable, we
can find the binding to skip for a protected variable; one binding and one
protection cancel each other; once an unprotected variable has a binding, it
is bound.
It is still just the usual lexical scoping in action - the only change is
that shadowed bindings can now be reached,
by protecting variables from shadowing bindings.
That is all one needs to know about the system at the
programmer-level, at least for a language like Javascript,
whose operational semantics isn't defined by rewrite
rules (*).
Hope this helps,
Claus
(*) As a student, I found programming with it very intuitive,
even though the language we were given did execute by
rewriting (so the protection keys adjusted to dynamically
changing program structure, e.g, when a function definition
was inlined at a call site);
implementers find it similar to deBruijn-Indices (if an implementation
renames all variables to be the same, the resulting protection keys
correspond directly to indices for stack access), but those are not usually
palatable to programmers; http://en.wikipedia.org/wiki/De_Bruijn_index
when reasoning about programs, or rewriting programs, it means that names
are less of a problem, because we can always preserve the binding structure
(no more exceptions like you can wrap code in a function,
provided the code does not mention the function
name or parameters).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Mar 26, 2011, at 6:44 AM, Wes Garland wrote:
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
end users (engineers and architects as well as scripters) could contribute to
the developer experience of using JavaScript
I was going to suggest comp.lang.javascript, but I just had a look and it
seems to have been taken over by DOM questions and spam. David, why don't
you start an ES Tech group or something, and ban questions which aren't
related to JS? (Copy your charter from comp.lang.c, maybe). Announce it
here, and I will subscribe. Probably even participate.
This es-discuss group sounds exactly like that ES Tech group -- why make a
new one?
If there's too much noise in any group, new or old, the group becomes useless.
Asking for some simple ambiguity checks before posting syntax strawmen, and
pleading to avoid one-line followups that overcite, etc. is *not* wrath. It's
part of the well-known netiquette standard, but not enforced much these days.
Hence the decline of USENET and NNTP, the rise of stackoverflow and the like.
Still a lot of noise in all the reddits, slashdots, etc. Voting/ranking can
help but cliques do game the system.
For ES Tech, let's use es-discuss. If someone thinks I called them a name
when I didn't, that's just bad on them. If I was rude, bad on me. We can patch
things up and move on.
And to be fair, the JS grammar is subtle enough that it's fine to propose
somehting that *might* work, only to have grammarians debug it.
So don't let me rain on anyone's parade, but please don't shoot entirely from
the hip. Read a bit on parsing and study the grammar, or just consider whether
what you propose is indistinguishable from what is already a valid expression
or expression followed by a statement.
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. `a,b { return a + b; }`
This is ambiguous too. A comma expression followed by a block (if in an outer
function, the return is legal).
C#, CoffeeScript, and other languages use - to link a formal parameter list to
a function body, which requires bottom-up parsing in general (with comma as
operator, as JS, C++, and C have; plus Harmony's destructuring and default
parameter value proposals).
Requiring bottom-up parsing has bounced off of implementors in the past, and
with JavaScriptCore switching from a Bison grammar to a top-down hand-coded
parser, I expect it will again.
I don't find syntax like this clear from a coder's POV, and there is the
re-tooling issue with highlighting editors and the ability to trivially
transform between the styles for faster adoption and old code minification --
while these issues certainly shouldn't be deciding factors for TC39 it is
nice that leading-char lparen...rparen makes most of them go away.
That's the idea. We need to keep this simple or it will probably fall apart,
either due to ambiguities, or implementors balking at too much complexity in
parsing with more power than top-down parsers have.
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
I've put examples of real world code chock-full of anonymous function
expressions in both leading-char (#) and angle-braketing styles here:
https://gist.github.com/67
Feel free to continue this discussion on that page, if inclined.
khs
On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich bren...@mozilla.com wrote:
On Mar 26, 2011, at 6:44 AM, Wes Garland wrote:
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
end users (engineers and architects as well as scripters) could contribute
to the developer experience of using JavaScript
I was going to suggest comp.lang.javascript, but I just had a look and it
seems to have been taken over by DOM questions and spam. David, why don't
you start an ES Tech group or something, and ban questions which aren't
related to JS? (Copy your charter from comp.lang.c, maybe). Announce it
here, and I will subscribe. Probably even participate.
This es-discuss group sounds exactly like that ES Tech group -- why make
a new one?
If there's too much noise in any group, new or old, the group becomes
useless. Asking for some simple ambiguity checks before posting syntax
strawmen, and pleading to avoid one-line followups that overcite, etc. is
*not* wrath. It's part of the well-known netiquette standard, but not
enforced much these days.
Hence the decline of USENET and NNTP, the rise of stackoverflow and the
like. Still a lot of noise in all the reddits, slashdots, etc.
Voting/ranking can help but cliques do game the system.
For ES Tech, let's use es-discuss. If someone thinks I called them a name
when I didn't, that's just bad on them. If I was rude, bad on me. We can
patch things up and move on.
And to be fair, the JS grammar is subtle enough that it's fine to propose
somehting that *might* work, only to have grammarians debug it.
So don't let me rain on anyone's parade, but please don't shoot entirely
from the hip. Read a bit on parsing and study the grammar, or just consider
whether what you propose is indistinguishable from what is already a valid
expression or expression followed by a statement.
Non leading-char solutions have the disadvantage of using some other kind
of bracketing -- e.g. `a,b { return a + b; }`
This is ambiguous too. A comma expression followed by a block (if in an
outer function, the return is legal).
C#, CoffeeScript, and other languages use - to link a formal parameter
list to a function body, which requires bottom-up parsing in general (with
comma as operator, as JS, C++, and C have; plus Harmony's destructuring and
default parameter value proposals).
Requiring bottom-up parsing has bounced off of implementors in the past,
and with JavaScriptCore switching from a Bison grammar to a top-down
hand-coded parser, I expect it will again.
I don't find syntax like this clear from a coder's POV, and there is the
re-tooling issue with highlighting editors and the ability to trivially
transform between the styles for faster adoption and old code minification
-- while these issues certainly shouldn't be deciding factors for TC39 it is
nice that leading-char lparen...rparen makes most of them go away.
That's the idea. We need to keep this simple or it will probably fall
apart, either due to ambiguities, or implementors balking at too much
complexity in parsing with more power than top-down parsers have.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
This is an interesting idea, never heard of it before. That said, it seems a better start for brainstorming than as an end of it. The previously-mentioned concerns about numbering being fragile seem real to me. Further, how would this interact with eval introducing (or in some systems even removing) lexical bindings? (Or maybe eval doesn't matter if this only applies in a new language mode with no eval-like construct -- I'm not up-to-date on how eval interacts with the latest language proposals.) Nevertheless this 35-year-old idea seems fresh in the context of ECMAScript development, and worth thinking about, so thanks for bringing it up. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On 03/26/2011 07:44 PM, Brendan Eich wrote:
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. `a,b { return a + b; }`
This is ambiguous too. A comma expression followed by a block (if in an outer
function, the return is legal).
I might be misreading, but I think Wes meant to have ` as a bracket-y character, such
that on seeing it you switch to argument-parsing mode until you hit '{', or something
like that, then end the entire thing with another ` (bracket-y character).
There's no ambiguity there that I can see, although it has other issues, and wasn't
seriously proposed anyway (as I read Wes).
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Mar 26, 2011, at 9:06 PM, Jeff Walden wrote:
On 03/26/2011 07:44 PM, Brendan Eich wrote:
Non leading-char solutions have the disadvantage of using some other kind
of bracketing -- e.g. `a,b { return a + b; }`
This is ambiguous too. A comma expression followed by a block (if in an
outer function, the return is legal).
I might be misreading, but I think Wes meant to have ` as a bracket-y
character, such that on seeing it you switch to argument-parsing mode until
you hit '{', or something like that, then end the entire thing with another `
(bracket-y character). There's no ambiguity there that I can see, although
it has other issues, and wasn't seriously proposed anyway (as I read Wes).
Oh, I took the `` as meta, not concrete. If concrete, they are already used for
quasis:
http://wiki.ecmascript.org/doku.php?id=strawman:quasis-smorgasboard
Any quote character delimiting suggest strings, not functions. JS doesn't have
to look like other languages in every corner of its syntax, but it does look
like some big ones in most respects already, and it's hard to argue for looking
like nothing ever seen before, here!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
That hash symbol
As a simple matter of taste, I find the # symbol to be quite ugly and have
been thinking of alternatives for shortening function expression syntax.
In working with my own wonky version of promises, I continue to make the
same typing error over and over again. This is something like what I mean
to type:
obj.doSomething().then(function(val, err)
{
...
});
But I find myself typing this instead:
obj.doSomething().then(val, err)
{
...
});
The problem isn't so much the extra typing of the function keyword, but
the profusion of parens. I'd like to suggest the following form instead.
obj.doSomething().then(val, err
{
...
});
Correct me if I'm wrong, but since expressions cannot start with , this
shouldn't present any problems for a top-down parser. Is that right?
Thanks,
khs
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
2011/3/25 Kevin Smith khs4...@gmail.com:
As a simple matter of taste, I find the # symbol to be quite ugly and have
been thinking of alternatives for shortening function expression syntax.
In working with my own wonky version of promises, I continue to make the
same typing error over and over again. This is something like what I mean
to type:
obj.doSomething().then(function(val, err)
{
...
});
But I find myself typing this instead:
obj.doSomething().then(val, err)
{
...
});
The problem isn't so much the extra typing of the function keyword, but
the profusion of parens. I'd like to suggest the following form instead.
obj.doSomething().then(val, err
{
...
});
Correct me if I'm wrong, but since expressions cannot start with , this
shouldn't present any problems for a top-down parser. Is that right?
Does this cause ambiguities with E4X ? https://developer.mozilla.org/en/e4x
Thanks,
khs
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
Oh, boogers! : )
On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel mikesam...@gmail.com wrote:
2011/3/25 Kevin Smith khs4...@gmail.com:
As a simple matter of taste, I find the # symbol to be quite ugly and
have
been thinking of alternatives for shortening function expression syntax.
In working with my own wonky version of promises, I continue to make the
same typing error over and over again. This is something like what I
mean
to type:
obj.doSomething().then(function(val, err)
{
...
});
But I find myself typing this instead:
obj.doSomething().then(val, err)
{
...
});
The problem isn't so much the extra typing of the function keyword, but
the profusion of parens. I'd like to suggest the following form instead.
obj.doSomething().then(val, err
{
...
});
Correct me if I'm wrong, but since expressions cannot start with ,
this
shouldn't present any problems for a top-down parser. Is that right?
Does this cause ambiguities with E4X ?
https://developer.mozilla.org/en/e4x
Thanks,
khs
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
Implicit functions?
globalMethod(argument)
{
// implementation
};
AnObject.prototype.method(value)
{
// whatevs
};
On 25 Mar 2011, at 17:28, Kevin Smith khs4...@gmail.com wrote:
Oh, boogers! : )
On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel mikesam...@gmail.com wrote:
2011/3/25 Kevin Smith khs4...@gmail.com:
As a simple matter of taste, I find the # symbol to be quite ugly and have
been thinking of alternatives for shortening function expression syntax.
In working with my own wonky version of promises, I continue to make the
same typing error over and over again. This is something like what I mean
to type:
obj.doSomething().then(function(val, err)
{
...
});
But I find myself typing this instead:
obj.doSomething().then(val, err)
{
...
});
The problem isn't so much the extra typing of the function keyword, but
the profusion of parens. I'd like to suggest the following form instead.
obj.doSomething().then(val, err
{
...
});
Correct me if I'm wrong, but since expressions cannot start with , this
shouldn't present any problems for a top-down parser. Is that right?
Does this cause ambiguities with E4X ? https://developer.mozilla.org/en/e4x
Thanks,
khs
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
2011/3/25 David Foley davi@gmail.com:
Implicit functions?
globalMethod(argument)
{
// implementation
};
AnObject.prototype.method(value)
{
// whatevs
};
Is this a proposed syntax?
If so, in the presence of semicolon insertion, isn't this ambiguous with
globalMethodCall(argument);
{
// block
}
; // noop
AnObject.prototype.methodCall(value);
{
// another block
}
; // noop
On 25 Mar 2011, at 17:28, Kevin Smith khs4...@gmail.com wrote:
Oh, boogers! : )
On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel mikesam...@gmail.com wrote:
2011/3/25 Kevin Smith khs4...@gmail.com:
As a simple matter of taste, I find the # symbol to be quite ugly and
have
been thinking of alternatives for shortening function expression syntax.
In working with my own wonky version of promises, I continue to make the
same typing error over and over again. This is something like what I
mean
to type:
obj.doSomething().then(function(val, err)
{
...
});
But I find myself typing this instead:
obj.doSomething().then(val, err)
{
...
});
The problem isn't so much the extra typing of the function keyword,
but
the profusion of parens. I'd like to suggest the following form
instead.
obj.doSomething().then(val, err
{
...
});
Correct me if I'm wrong, but since expressions cannot start with ,
this
shouldn't present any problems for a top-down parser. Is that right?
Does this cause ambiguities with E4X ?
https://developer.mozilla.org/en/e4x
Thanks,
khs
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
It's totally ambiguous.
Suggestion: do not mail syntax ideas without working through (pencil and paper,
Jison/Bison/Antlr/something, or better) the grammar.
More specific suggestion: don't bikeshed function syntax without a new prefix
character or a convincing top-down parsing story. If you don't know what
top-down vs. bottom-up means, find out first.
/be
On Mar 25, 2011, at 10:32 AM, Mike Samuel wrote:
2011/3/25 David Foley davi@gmail.com:
Implicit functions?
globalMethod(argument)
{
// implementation
};
AnObject.prototype.method(value)
{
// whatevs
};
Is this a proposed syntax?
If so, in the presence of semicolon insertion, isn't this ambiguous with
globalMethodCall(argument);
{
// block
}
; // noop
AnObject.prototype.methodCall(value);
{
// another block
}
; // noop
On 25 Mar 2011, at 17:28, Kevin Smith khs4...@gmail.com wrote:
Oh, boogers! : )
On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel mikesam...@gmail.com wrote:
2011/3/25 Kevin Smith khs4...@gmail.com:
As a simple matter of taste, I find the # symbol to be quite ugly and
have
been thinking of alternatives for shortening function expression syntax.
In working with my own wonky version of promises, I continue to make the
same typing error over and over again. This is something like what I
mean
to type:
obj.doSomething().then(function(val, err)
{
...
});
But I find myself typing this instead:
obj.doSomething().then(val, err)
{
...
});
The problem isn't so much the extra typing of the function keyword,
but
the profusion of parens. I'd like to suggest the following form
instead.
obj.doSomething().then(val, err
{
...
});
Correct me if I'm wrong, but since expressions cannot start with ,
this
shouldn't present any problems for a top-down parser. Is that right?
Does this cause ambiguities with E4X ?
https://developer.mozilla.org/en/e4x
Thanks,
khs
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
Sure - no offense or time-wasting intended.
On Fri, Mar 25, 2011 at 1:34 PM, Brendan Eich bren...@mozilla.com wrote:
It's totally ambiguous.
Suggestion: do not mail syntax ideas without working through (pencil and
paper, Jison/Bison/Antlr/something, or better) the grammar.
More specific suggestion: don't bikeshed function syntax without a new
prefix character or a convincing top-down parsing story. If you don't know
what top-down vs. bottom-up means, find out first.
/be
On Mar 25, 2011, at 10:32 AM, Mike Samuel wrote:
2011/3/25 David Foley davi@gmail.com:
Implicit functions?
globalMethod(argument)
{
// implementation
};
AnObject.prototype.method(value)
{
// whatevs
};
Is this a proposed syntax?
If so, in the presence of semicolon insertion, isn't this ambiguous with
globalMethodCall(argument);
{
// block
}
; // noop
AnObject.prototype.methodCall(value);
{
// another block
}
; // noop
On 25 Mar 2011, at 17:28, Kevin Smith khs4...@gmail.com wrote:
Oh, boogers! : )
On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel mikesam...@gmail.com
wrote:
2011/3/25 Kevin Smith khs4...@gmail.com:
As a simple matter of taste, I find the # symbol to be quite ugly and
have
been thinking of alternatives for shortening function expression
syntax.
In working with my own wonky version of promises, I continue to make
the
same typing error over and over again. This is something like what I
mean
to type:
obj.doSomething().then(function(val, err)
{
...
});
But I find myself typing this instead:
obj.doSomething().then(val, err)
{
...
});
The problem isn't so much the extra typing of the function keyword,
but
the profusion of parens. I'd like to suggest the following form
instead.
obj.doSomething().then(val, err
{
...
});
Correct me if I'm wrong, but since expressions cannot start with ,
this
shouldn't present any problems for a top-down parser. Is that right?
Does this cause ambiguities with E4X ?
https://developer.mozilla.org/en/e4x
Thanks,
khs
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
Is this a proposed syntax?
No- It was an off the cuff reaction
Suggestion: do not mail syntax
Noted
On 25 Mar 2011, at 17:34, Brendan Eich bren...@mozilla.com wrote:
It's totally ambiguous.
Suggestion: do not mail syntax ideas without working through (pencil and
paper, Jison/Bison/Antlr/something, or better) the grammar.
More specific suggestion: don't bikeshed function syntax without a new prefix
character or a convincing top-down parsing story. If you don't know what
top-down vs. bottom-up means, find out first.
/be
On Mar 25, 2011, at 10:32 AM, Mike Samuel wrote:
2011/3/25 David Foley davi@gmail.com:
Implicit functions?
globalMethod(argument)
{
// implementation
};
AnObject.prototype.method(value)
{
// whatevs
};
Is this a proposed syntax?
If so, in the presence of semicolon insertion, isn't this ambiguous with
globalMethodCall(argument);
{
// block
}
; // noop
AnObject.prototype.methodCall(value);
{
// another block
}
; // noop
On 25 Mar 2011, at 17:28, Kevin Smith khs4...@gmail.com wrote:
Oh, boogers! : )
On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel mikesam...@gmail.com wrote:
2011/3/25 Kevin Smith khs4...@gmail.com:
As a simple matter of taste, I find the # symbol to be quite ugly and
have
been thinking of alternatives for shortening function expression syntax.
In working with my own wonky version of promises, I continue to make the
same typing error over and over again. This is something like what I
mean
to type:
obj.doSomething().then(function(val, err)
{
...
});
But I find myself typing this instead:
obj.doSomething().then(val, err)
{
...
});
The problem isn't so much the extra typing of the function keyword,
but
the profusion of parens. I'd like to suggest the following form
instead.
obj.doSomething().then(val, err
{
...
});
Correct me if I'm wrong, but since expressions cannot start with ,
this
shouldn't present any problems for a top-down parser. Is that right?
Does this cause ambiguities with E4X ?
https://developer.mozilla.org/en/e4x
Thanks,
khs
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
No problem -- just don't provoke Zeus to unleash the Crock-en ;-).
https://mail.mozilla.org/pipermail/es-discuss/2011-February/012761.html
/be
On Mar 25, 2011, at 10:39 AM, Kevin Smith wrote:
Sure - no offense or time-wasting intended.
On Fri, Mar 25, 2011 at 1:34 PM, Brendan Eich bren...@mozilla.com wrote:
It's totally ambiguous.
Suggestion: do not mail syntax ideas without working through (pencil and
paper, Jison/Bison/Antlr/something, or better) the grammar.
More specific suggestion: don't bikeshed function syntax without a new prefix
character or a convincing top-down parsing story. If you don't know what
top-down vs. bottom-up means, find out first.
/be
On Mar 25, 2011, at 10:32 AM, Mike Samuel wrote:
2011/3/25 David Foley davi@gmail.com:
Implicit functions?
globalMethod(argument)
{
// implementation
};
AnObject.prototype.method(value)
{
// whatevs
};
Is this a proposed syntax?
If so, in the presence of semicolon insertion, isn't this ambiguous with
globalMethodCall(argument);
{
// block
}
; // noop
AnObject.prototype.methodCall(value);
{
// another block
}
; // noop
On 25 Mar 2011, at 17:28, Kevin Smith khs4...@gmail.com wrote:
Oh, boogers! : )
On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel mikesam...@gmail.com wrote:
2011/3/25 Kevin Smith khs4...@gmail.com:
As a simple matter of taste, I find the # symbol to be quite ugly and
have
been thinking of alternatives for shortening function expression syntax.
In working with my own wonky version of promises, I continue to make the
same typing error over and over again. This is something like what I
mean
to type:
obj.doSomething().then(function(val, err)
{
...
});
But I find myself typing this instead:
obj.doSomething().then(val, err)
{
...
});
The problem isn't so much the extra typing of the function keyword,
but
the profusion of parens. I'd like to suggest the following form
instead.
obj.doSomething().then(val, err
{
...
});
Correct me if I'm wrong, but since expressions cannot start with ,
this
shouldn't present any problems for a top-down parser. Is that right?
Does this cause ambiguities with E4X ?
https://developer.mozilla.org/en/e4x
Thanks,
khs
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Fri, Mar 25, 2011 at 11:24 AM, Brendan Eich bren...@mozilla.com wrote: No problem -- just don't provoke Zeus to unleash the Crock-en ;-). https://mail.mozilla.org/pipermail/es-discuss/2011-February/012761.html Perhaps there needs to be a venue where non-experts can bounce ideas and discuss points of pain with volunteering committee members to reduce noise in this venue. There is little room here for light-hearted discussion and mentoring for members of the community who have less than full-time commitment and years of experience in language design. It's disappointing to be ostracized, but it is true. I also want to see careful and well-wrought steady progress. I remember a former decade when this discussion was impossible to follow, too many bad ideas were too thoroughly discussed, and much time was wasted. Kris Kowal ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
Dunno. You were ravaged by the Crocken so you may be a bit sore still :-/. Any list with informal/unsound syntax talk is not one I want to be on. It's not quite beer talk. It could lead to a breakthrough idea, who knows? But the cost is pretty high. I'm not against syntax proposals here, mind you. Let's just work out the grammar a bit before launching. /be On Mar 25, 2011, at 12:09 PM, Kris Kowal wrote: On Fri, Mar 25, 2011 at 11:24 AM, Brendan Eich bren...@mozilla.com wrote: No problem -- just don't provoke Zeus to unleash the Crock-en ;-). https://mail.mozilla.org/pipermail/es-discuss/2011-February/012761.html Perhaps there needs to be a venue where non-experts can bounce ideas and discuss points of pain with volunteering committee members to reduce noise in this venue. There is little room here for light-hearted discussion and mentoring for members of the community who have less than full-time commitment and years of experience in language design. It's disappointing to be ostracized, but it is true. I also want to see careful and well-wrought steady progress. I remember a former decade when this discussion was impossible to follow, too many bad ideas were too thoroughly discussed, and much time was wasted. Kris Kowal ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
Le 25/03/2011 20:18, Brendan Eich a écrit : Dunno. You were ravaged by the Crocken so you may be a bit sore still :-/. Any list with informal/unsound syntax talk is not one I want to be on. It's not quite beer talk. It could lead to a breakthrough idea, who knows? But the cost is pretty high. I'm not against syntax proposals here, mind you. Let's just work out the grammar a bit before launching. This is said and (hopefully) read by people who are currently on the list. But it might be worth saying it while welcoming people on es-discuss (on the listinfo page or welcoming e-mail after validation) so that each time someone comes in with the expectation of bringing a syntax idea, s/he can be told beforehand that s/he should start working on the grammar and bring something already solid to the mailing-list. I haven't taken the occasion to do so yet, but I'd like to thank you for considering that an open mailing-list will be beneficial for ECMAScript as a language. Nevertheless, by doing so, you're creating a community and like every community, there are rules, conventions, expectations. It might be time to formalize these in a way or another. The WHATWG has done it on their wiki. For inspiration, I recommend reading: * http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F * http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F * http://wiki.whatwg.org/wiki/FAQ#Mailing_List Regards, David /be On Mar 25, 2011, at 12:09 PM, Kris Kowal wrote: On Fri, Mar 25, 2011 at 11:24 AM, Brendan Eich bren...@mozilla.com wrote: No problem -- just don't provoke Zeus to unleash the Crock-en ;-). https://mail.mozilla.org/pipermail/es-discuss/2011-February/012761.html Perhaps there needs to be a venue where non-experts can bounce ideas and discuss points of pain with volunteering committee members to reduce noise in this venue. There is little room here for light-hearted discussion and mentoring for members of the community who have less than full-time commitment and years of experience in language design. It's disappointing to be ostracized, but it is true. I also want to see careful and well-wrought steady progress. I remember a former decade when this discussion was impossible to follow, too many bad ideas were too thoroughly discussed, and much time was wasted. Kris Kowal ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
That's something I for one would welcome, and I'm sure others too. I'd like to see some traction on this On 25 Mar 2011, at 20:38, David Bruant david.bru...@labri.fr wrote: Le 25/03/2011 20:18, Brendan Eich a écrit : Dunno. You were ravaged by the Crocken so you may be a bit sore still :-/. Any list with informal/unsound syntax talk is not one I want to be on. It's not quite beer talk. It could lead to a breakthrough idea, who knows? But the cost is pretty high. I'm not against syntax proposals here, mind you. Let's just work out the grammar a bit before launching. This is said and (hopefully) read by people who are currently on the list. But it might be worth saying it while welcoming people on es-discuss (on the listinfo page or welcoming e-mail after validation) so that each time someone comes in with the expectation of bringing a syntax idea, s/he can be told beforehand that s/he should start working on the grammar and bring something already solid to the mailing-list. I haven't taken the occasion to do so yet, but I'd like to thank you for considering that an open mailing-list will be beneficial for ECMAScript as a language. Nevertheless, by doing so, you're creating a community and like every community, there are rules, conventions, expectations. It might be time to formalize these in a way or another. The WHATWG has done it on their wiki. For inspiration, I recommend reading: * http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F * http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F * http://wiki.whatwg.org/wiki/FAQ#Mailing_List Regards, David /be On Mar 25, 2011, at 12:09 PM, Kris Kowal wrote: On Fri, Mar 25, 2011 at 11:24 AM, Brendan Eich bren...@mozilla.com wrote: No problem -- just don't provoke Zeus to unleash the Crock-en ;-). https://mail.mozilla.org/pipermail/es-discuss/2011-February/012761.html Perhaps there needs to be a venue where non-experts can bounce ideas and discuss points of pain with volunteering committee members to reduce noise in this venue. There is little room here for light-hearted discussion and mentoring for members of the community who have less than full-time commitment and years of experience in language design. It's disappointing to be ostracized, but it is true. I also want to see careful and well-wrought steady progress. I remember a former decade when this discussion was impossible to follow, too many bad ideas were too thoroughly discussed, and much time was wasted. Kris Kowal ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Mar 25, 2011, at 2:07 PM, David Foley wrote: That's something I for one would welcome, and I'm sure others too. I'd like to see some traction on this I don't want to spend too much time on custom etiquette. Also I don't want to be a jerk about it, but your post both bottom-cites heavily (top-citing without editing is even worse, but please trim; I nag everyone and fail myself, so again don't take this as more than a chance to restate an old USENET rule). Another thing: you'd like to see some traction on this, my favorite pronoun. Which this? If you don't like # for sharp functions, then we're back to inventing syntax. That requires some care not to walk right into (fairly well-known, but trickier due to ASI and lack of ASI where you expected it) grammatical ambiguities. Throwing up ideas and letting the grammarians debug them on the list is possible and might be fun but (in my view; I'm not the list moderator, just admin -- we have no moderator) it's not a good use of the list or all our time. So: top-cite and trim carefully, avoid pronoun trouble, and try to make concrete proposals where (if they involve new syntax) you've worked through some of the consequences to avoid the obvious gotchas. This may be too much to ask, but I'll ask for it anyway. It ought not cause a swerve into OMG fascist list rules. But some of us old timers expect at least the old netiquette rules to apply still. Follow them and the Crocken may stay peacefully asleep. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
My response was simply this : assuming normative scope in conversational tone, that I would welcome is a venue where end users (engineers and architects as well as scripters) could contribute to the developer experience of using JavaScript without incurring the wrath of it's fathers, which appear to be more focused on the interpreter of the language rather than the thrust of it's use cases (which almost always appear to bottom out on library abstractions to solve the issues). I really would have hoped that rather than assuming an asses POV that this list would assume the best without requirement of over-qualification. Like it or not, JavaScript is the glue of the web. This language space has been embroiled in vendor politics since day one- end users need an effective forum to describe their requirements- that is what I was espousing. Clear enough? You do yourself a disservice by assuming idiocracy. On 25 Mar 2011, at 22:49, Brendan Eich bren...@mozilla.com wrote: On Mar 25, 2011, at 2:07 PM, David Foley wrote: That's something I for one would welcome, and I'm sure others too. I'd like to see some traction on this I don't want to spend too much time on custom etiquette. Also I don't want to be a jerk about it, but your post both bottom-cites heavily (top-citing without editing is even worse, but please trim; I nag everyone and fail myself, so again don't take this as more than a chance to restate an old USENET rule). Another thing: you'd like to see some traction on this, my favorite pronoun. Which this? If you don't like # for sharp functions, then we're back to inventing syntax. That requires some care not to walk right into (fairly well-known, but trickier due to ASI and lack of ASI where you expected it) grammatical ambiguities. Throwing up ideas and letting the grammarians debug them on the list is possible and might be fun but (in my view; I'm not the list moderator, just admin -- we have no moderator) it's not a good use of the list or all our time. So: top-cite and trim carefully, avoid pronoun trouble, and try to make concrete proposals where (if they involve new syntax) you've worked through some of the consequences to avoid the obvious gotchas. This may be too much to ask, but I'll ask for it anyway. It ought not cause a swerve into OMG fascist list rules. But some of us old timers expect at least the old netiquette rules to apply still. Follow them and the Crocken may stay peacefully asleep. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
