Waldemar Horwat wrote:
Consensus on:
- Have only one arrow, namely =
- this is always static. No provision for dynamic this.
- Other than the treatment of this, the function behaves like a normal
function. return, break, etc. behave as though the function body were
in a function(...){...}.
To
: Thursday, March 29, 2012 02:30
To: Waldemar Horwat
Cc: es-discuss
Subject: Re: March 28 meeting notes
Waldemar Horwat wrote:
Consensus on:
- Have only one arrow, namely =
- this is always static. No provision for dynamic this.
- Other than the treatment of this, the function behaves like
Domenic Denicola wrote:
Minor question: There are no examples of very empty arrow functions, e.g. `=`
or `= 5`. And from what I can tell reading the grammar , they are not allowed.
They were allowed in the grammar I wrote -- see the wiki history.
Several TC39ers reacted badly to them
Any discussion on maximal minimal classes? Just curious of the status.
- Russ
On Wed, Mar 28, 2012 at 8:42 PM, Waldemar Horwat walde...@google.comwrote:
Here are my rough notes from today's meeting.
Waldemar
-
IPR discussion
Intel changed their ECMAScript patent declaration to
On 29 March 2012 16:11, Brendan Eich bren...@mozilla.org wrote:
There was a lengthy discussion of what TCP means. JS has statements as
well as expressions, it's the C curse by way of make it look like Java.
So adding a TCP lambda form now, however good for macros, compiler writers,
and
On Wed, Mar 28, 2012 at 11:47 PM, Erik Corry erik.co...@gmail.com wrote:
2012/3/29 Waldemar Horwat walde...@google.com:
Wild debate.
Poll of who objects to which problem in the proposal:
1. AWB, MM, AR, AR, LH, DC, WH, DH
2. AWB, MM, AR, AR, LH, BE, DC, WH, DH
3. AR, AR, LH, DC, BE
5.
On Mar 29, 2012, at 6:23 AM, Domenic Denicola wrote:
Bigger question: It sounds like TCP was sacrificed in favor of maximal
minimalism, which makes sense.
No, maximal minimalism is not our universal principle for ES6. It's important
for classes, for various reasons, but it's not our approach
For me it was a tradeoff. I prefer consistency. The treatment of
'this' was done TCP-style, so I'd have preferred for the other
language constructs to also behave TCP-style. However, practical
gotchas begin to form:
- yield cannot be done TCP-style within the framework of what we're doing.
- what
Andreas Rossberg wrote:
On 29 March 2012 16:11, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Yesterday, Luke made a stronger point: TCP 'return' means async
callbacks (e.g. promise when functions) must be written ML-style,
with return value in tail position.
Russell Leggett wrote:
Any discussion on maximal minimal classes? Just curious of the status.
Was not on yesterday's agenda.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Thu, Mar 29, 2012 at 3:13 PM, Brendan Eich bren...@mozilla.org wrote:
Russell Leggett wrote:
Any discussion on maximal minimal classes? Just curious of the status.
Was not on yesterday's agenda.
Thanks. I'll just keep an eye open.
- Russ
/be
On 29 March 2012 20:35, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg wrote:
On 29 March 2012 16:11, Brendan Eich bren...@mozilla.org mailto:
bren...@mozilla.org wrote:
Yesterday, Luke made a stronger point: TCP 'return' means async
callbacks (e.g. promise when functions)
Andreas Rossberg wrote:
For me, the biggest blow against TCP lambda forms in general was
Mark's observation regarding the incompatibility with 'yield' that you
mention in the other post.
It seems 'yield' may be a red herring. We all forgot that it is
contextually defined as a keyword only
On 29 March 2012 21:26, Brendan Eich bren...@mozilla.org wrote:
Nice. This gives functions some of the oomph of block-lambdas (see
https://gist.github.com/**1677893 https://gist.github.com/1677893 from
@wavded [Marc Harter]). However:
* Requires function declarations, or seems to -- too
In order to avoid contributing to the list of exceptions to TCP for
non-rejected programs, we need to reject yield in these positions. And
it is upwards compatible since arrow functions are new. And as you observe,
less confusing.
With such a yield prohibited, AFAICT the exceptions in
Andreas Rossberg wrote:
I was thinking, it should be possible to extend arrow syntax to allow
an optional name? As in:
f(n) = n==0 ? 1 : x * f(n-1)
I know you're not proposing, but this would have to be a separate
proposal. I fear adding it to arrow function syntax will lose consensus.
On 29 March 2012 22:26, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg wrote:
For me, the biggest blow against TCP lambda forms in general was Mark's
observation regarding the incompatibility with 'yield' that you mention in
the other post.
It seems 'yield' may be a red herring.
On 29 March 2012 22:37, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg wrote:
I was thinking, it should be possible to extend arrow syntax to allow an
optional name? As in:
f(n) = n==0 ? 1 : x * f(n-1)
I know you're not proposing, but this would have to be a separate proposal.
Andreas Rossberg wrote:
Ah, no, I was thinking of this as still being purely an expression,
not extending its meaning to be a declaration. That is, the function
name is only visible in the body. I completely agree that all
declaration statements should start with a keyword.
Ok, I'm with you.
Andreas Rossberg wrote:
To me, that seems like a complete roadblock wrt the primary motivation
for TCP lambdas.
From yesterday's meeting, it seems one of many. Too many, and perhaps
it's the clearest roadblock as you suggest, but altogether and due to
many fallen stones, the road is blocked.
20 matches
Mail list logo
