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
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 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
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
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
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
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
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
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*
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
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
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
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
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 ^
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,
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
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 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:
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
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
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
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
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
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
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,
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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 :-/.
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
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
65 matches
Mail list logo
