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 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
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
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
>
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 an
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 tha
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
On Mar 30, 2011, at 5:06 AM, Sam Tobin-Hochstadt wrote:
> On Tue, Mar 29, 2011 at 7:08 PM, Allen Wirfs-Brock
> 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
>> disting
On Tue, Mar 29, 2011 at 7:08 PM, Allen Wirfs-Brock
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
>> wrote:
>>>
>>> JavaScript up to this point seems to have done a pretty good job of
>>> balancing the OO and functional
Summarizing the state of proposals from your discussion:
function foo(arg1, arg2) {...} // implicit parameter/receiver 'this'
#foo(this | arg1, arg2) {...} // implicit parameter/receiver 'this'
#foo( arg1, arg2) {...}// no implicit parameter/receiver
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
> paramete
2011/3/29 Mike Samuel :
> 2011/3/29 Bob Nystrom :
>> 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 ju
On Mar 29, 2011, at 3:03 PM, Sam Tobin-Hochstadt wrote:
> On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
> 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
2011/3/29 Bob Nystrom :
> 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
> A
>
> 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, b
On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
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
> s
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
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
> li
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
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
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, eit
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 ^ /
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
c
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 pro
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 har
On Tue, Mar 29, 2011 at 12:12 AM, Allen Wirfs-Brock
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 usin
On Mar 28, 2011, at 10:35 AM, Allen Wirfs-Brock 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
On Tue, Mar 29, 2011 at 4:16 AM, Erik Arvidsson wrote:
> 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'.
>
`self` will almost d
On Mar 28, 2011, at 8:30 PM, Sam Tobin-Hochstadt wrote:
> On Mon, Mar 28, 2011 at 10:16 PM, Erik Arvidsson
> wrote:
>> On Mon, Mar 28, 2011 at 10:35, Allen Wirfs-Brock
>> wrote:
>>> Overall, I really like ^this as a narrow solution to a specific real usage
>>> problem. I'm interested in react
On Mon, Mar 28, 2011 at 10:16 PM, Erik Arvidsson
wrote:
> On Mon, Mar 28, 2011 at 10:35, Allen Wirfs-Brock
> 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 to
On Mon, Mar 28, 2011 at 10:35, Allen Wirfs-Brock 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 ^th
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'
> 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, suitabl
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,
Here, cant we use "^" instead of "#", I dont think it will conflict
with existing "bit xor" operator.
Like:-
function Outer() {
var x = "outer";
function Inner() {
var x = "inner";
log(x); // "inner"
log(^x); // "outer"
log(^^x); // global scope, probably unbound
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 a
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
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 reflect
2011/3/27 Wes Garland :
> On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich wrote:
> FunctionExpression :
> function Identifieropt ( FormalParameterListopt ) { FunctionBody }
> or
> `Identifieropt FormalParameterListopt { FunctionBody }`
> ..although my "native thought pattern" is definitely LALR(
2011/3/26 Jeff Walden :
> 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,
On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich 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
p
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: b
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
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 misrea
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 r
Thanks -- gists and github's discussion support are good for detailed syntax
snippet back and forth, now that you mention it. Better than plain old mail for
fast and focused interaction.
The <> for formal parameter lists won't fly in committee, I'm pretty sure. Not
just due to E4X but because o
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 wrote:
On Mar 26, 2011, at 6:44 AM, Wes Garland wrote:
> On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich 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 (e
2011/3/26 Mike Samuel :
> 2011/3/26 Claus Reinke :
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
2011/3/26 Claus Reinke :
>>> 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 skip
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 cl
2011/3/26 Claus Reinke :
>> 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
>>
2011/3/26 Wes Garland :
> On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich 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 arch
On Mar 26, 2011, at 6:44 AM, Wes Garland wrote:
> On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich 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 u
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich 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 con
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 method
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
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 appea
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
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 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
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
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 y
On Fri, Mar 25, 2011 at 11:24 AM, Brendan Eich 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
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 wr
>> 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 wrote:
> It's totally ambiguous.
>
> Suggestion: do not mail syntax ideas without working through (pencil and
> paper, Jison/Bison/Antlr/something,
Sure - no offense or time-wasting intended.
On Fri, Mar 25, 2011 at 1:34 PM, Brendan Eich 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
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
2011/3/25 David Foley :
> 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);
{
Implicit functions?
globalMethod(argument)
{
// implementation
};
AnObject.prototype.method(value)
{
// whatevs
};
On 25 Mar 2011, at 17:28, Kevin Smith wrote:
> Oh, boogers! : )
>
>
> On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel wrote:
> 2011/3/25 Kevin Smith :
> > As a simple ma
Oh, boogers! : )
On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel wrote:
> 2011/3/25 Kevin Smith :
> > 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
2011/3/25 Kevin Smith :
> 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 i
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
72 matches
Mail list logo
