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
Brendan Eich wrote:
Kevin Smith wrote:
I hate the CoffeeScript deviation, though. It's just confusing for
anyone who ever learned that fat-arrow binds |this| and thin-arrow
doesn't.
True. On the other hand, all arrows bind |this| is also quite simple
and easy to remember.
Yes, and I kept
Great to gain consensus indeed. This looks just about as nice as it can be.
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. Is this necessary? CoffeeScript's allowance of `- (expr)`
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
Herby Vojčík wrote:
Question 1: Do people want it? Do TC39 plan to have it in ES.next?
No, not in the block-lambda TCP sense. See my mail of 7:11am today. At
most the desire is for an equivalence over expressions, not statements:
e ~= do { e; }
So |this| must work, and we ban 'arguments'
Brendan Eich wrote:
I forgot to mention 'yield' in the 7:11am mail -- it was good catch
by Mark. Generators require a * in the head, after function or before
the generator function's name. Arrows cannot be generators, there's no
place for the * and YAGNI. Therefore 'yield' is not allowed, as
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
We are achieving a weaker form of almost-TCP that is close enough to have
many nice properties.
e is like (()=(e))()
for programs which are not not statically rejected, except for return.
The other TCP violations:
* lexical this fixes the this violation.
* banning a free[1] arguments,
On 29 March 2012 17:11, Mark S. Miller erig...@google.com wrote:
In listing these, I realize just now that we missed one from the
discussion yesterday. Does var hoist across a =?
Ah, nice, that's a good one, too.
The two weak-almost-TCP-respecting answers are yes and programs with
such
On Thu, Mar 29, 2012 at 8:30 AM, Andreas Rossberg rossb...@google.comwrote:
On 29 March 2012 17:11, Mark S. Miller erig...@google.com wrote:
In listing these, I realize just now that we missed one from the
discussion yesterday. Does var hoist across a =?
Ah, nice, that's a good one, too.
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.
Mark S. Miller wrote:
e is like (()=(e))()
Nit: no need to over-parenthesize the e in the right-hand side:
e is like (() = e)()
(Andreas raised this at the end of the meeting but said function at
first before correcting to arrow function -- big difference! ;-)
In listing these, I
Few questions on this new arrow functions:
let foo = x = x * x
1. What is foo.prototype ?
2. What does new foo(y) does ?
3. Is there going to be equivalent of Function for arrow functions ?
4. Is Function.create(foo) going to work ?
5. Will foo.call, foo.apply pass in the `this` ?
Regards
--
Irakli Gozalishvili wrote:
Few questions on this new arrow functions:
let foo = x = x * x
1. What is foo.prototype ?
2. What does new foo(y) does ?
The idea with arrow function syntax (as opposed to block-lambda revival)
was to be as close to just syntax for functions. Obviously we've made
Brendan Eich wrote:
Irakli Gozalishvili wrote:
Few questions on this new arrow functions:
let foo = x = x * x
1. What is foo.prototype ?
2. What does new foo(y) does ?
The idea with arrow function syntax (as opposed to block-lambda
revival) was to be as close to just syntax for functions.
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.
On Thu, Mar 29, 2012 at 12:02 PM, Brendan Eich bren...@mozilla.org wrote:
Brendan Eich wrote:
Irakli Gozalishvili wrote:
Few questions on this new arrow functions:
let foo = x = x * x
1. What is foo.prototype ?
2. What does new foo(y) does ?
The idea with arrow function syntax (as
Interesting. So x = x * x is not just syntactic sugar for
function (x) { return x * x }.bind(this)
On Mar 29, 2012, at 21:02 , Brendan Eich wrote:
Brendan Eich wrote:
Irakli Gozalishvili wrote:
Few questions on this new arrow functions:
let foo = x = x * x
1. What is
My bad. It is, minus [[Construct]] and *.prototype. I misremembered how bind()
works.
On Mar 30, 2012, at 0:01 , Axel Rauschmayer wrote:
Interesting. So x = x * x is not just syntactic sugar for
function (x) { return x * x }.bind(this)
--
Dr. Axel Rauschmayer
a...@rauschma.de
On Mar 28, 2012, at 2:19 PM, Erik Arvidsson wrote:
With your proposal I have to do let f = obj.foo;
obj::f which is even longer than the original.
That's not a fair argument. There's no need for the let-binding; you can write
obj::obj.foo
or
::obj.foo
Now, you might feel that it's
John J Barton wrote:
And like require.js we will have difficulty resynchronizing the script
loading with document loading. For example, the above code may fail if
the callback fires before 'myelement' is parsed.
That's a bug on the HTML author's part. The 'myelement' declaring markup
must
On Thu, Mar 29, 2012 at 4:55 PM, David Herman dher...@mozilla.com wrote:
On Mar 29, 2012, at 4:47 PM, John J Barton wrote:
And like require.js we will have difficulty resynchronizing the script
loading with document loading. For example, the above code may fail if the
callback fires before
I don't think the report on maximally minimal classes fully reflections the
discussion:
Maximally minimal classes:
Alex and Allen initiated the discussion as a status up-date to TC-39.. We
pointed out that this proposal had recently been extensively discussed on
es-discuss and that it
I've worked on a generic Set polyfill. It is quite a simple task to
build one but determining if an object is in the set is O(n) with the
following has method.
Set.prototype.has = function(element) {
for (var i = 0, ilen = this._elements.length; i ilen; i++) {
if (element
Peter Michaux wrote:
I've worked on a generic Set polyfill. It is quite a simple task to
build one but determining if an object is in the set is O(n) with the
following has method.
Set.prototype.has = function(element) {
for (var i = 0, ilen = this._elements.length; i ilen; i++)
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich bren...@mozilla.org wrote:
The January 19 2012 meeting notes recorded here:
https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html
include At next meeting MarkM will present a tiny API proposal for maps and
sets.
Has this
40 matches
Mail list logo
