Right now, please ask Ecma International to give me a Creative Commons
free-culture license (without NonCommercial nor NoDerivatives) so that I
can distribute the document to others with the same license.
___
es-discuss mailing list
Hi, I do not know if this is the correct list to discuss these things. If it is
not, please redirect me.
I have done some work on implementing the AP2 draft I could find here
http://github.com/domenic/promises-unwrapping and I have a few potential bugs
to report. If this is not the latest
Hi all, I just found a post that the current generator syntax
(function *) seems have decided in:
https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
According to the post, the biggest reason the star syntax is adopted
for now is that you cannot write empty generators with
Filip Pizlo wrote:
I think it's better if you pick one use case and get it totally right.
You're not going to get the optimize my JS code with types use case
right. So stick to the binary data mapping use case, and allow
arbitrary aliasing.
I am on the same page; any quibbling from me
The empty-body basis case is one reason. A stronger reason is that yield
is not a reserved identifier, and it is used in existing content, so
function* allows contextual reservation without breaking backward
compatibility.
Another reason is to clue readers in early, when reading in source
On Aug 31, 2013, at 12:15 PM, Yuichi Nishiwaki yuichi.nishiw...@gmail.com
wrote:
Hi all, I just found a post that the current generator syntax
(function *) seems have decided in:
https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
According to the post, the biggest
ES5 specifies yield as a reserved keyword, right? So there should be
no need to make it contextual.
2013/9/1 Brendan Eich bren...@mozilla.com:
The empty-body basis case is one reason. A stronger reason is that yield is
not a reserved identifier, and it is used in existing content, so function*
Yuichi Nishiwaki mailto:yuichi.nishiw...@gmail.com
August 31, 2013 12:45 PM
ES5 specifies yield as a reserved keyword, right?
Wrong, only ES5 strict reserved yield.
So there should be
no need to make it contextual.
There is; when we first tried reserving yield in 2006, we had to put
it
I can't get the point, why you need to know if the function is a
generator or not at a glance?
1. Forcing users to mark the function as a generator is only a
duplication. It basically doesn't have any meaning other than
double-checking, and fundamental risk for the unintentional creation
is still
Let's not go in circles -- the primary reason for function* is because
yield is not reserved in JS and is used by web content as a plain
identifier. It is a low-precedence unary prefix operator, so cannot be
contextually reserved by a grammatical restriction as module can. It
needs opt-in
The diagnosis and fix for these seem correct. Now reported at
https://github.com/domenic/promises-unwrapping/issues/14
https://github.com/domenic/promises-unwrapping/issues/15
Thanks for reporting these!
___
es-discuss mailing list
OK, right. I understand my first propose does not work. :-|
So one more question is how about making '*' optional in strict mode?
(Should I separate the topic to another?)
2013/9/1 Brendan Eich bren...@mozilla.com:
Let's not go in circles -- the primary reason for function* is because yield
is
On Sat, Aug 31, 2013 at 1:14 PM, Yuichi Nishiwaki
yuichi.nishiw...@gmail.com wrote:
OK, right. I understand my first propose does not work. :-|
So one more question is how about making '*' optional in strict mode?
(Should I separate the topic to another?)
2013/9/1 Brendan Eich
Mark's reply helps, but I want to add that we are *not* making
gratuitous differences between strict and non-strict mode. Modes are
bad, one is more than enough. Further speciation in later editions just
makes more. Just say no, write that * after function, and get on with
life :-).
/be
Indeed, thanks Nathan! Feel free to file issues, or even submit pull requests,
for any further bugs you encounter. That’s why we’re doing this on GitHub,
after all! :)
From: Mark S. Miller [mailto:erig...@google.com]
Sent: Saturday, August 31, 2013 16:14
To: Nathan Wall
Cc:
I am one of those on TC39 that want the visible flag. Since, in my view,
the only non-mistaken need to preserve sloppy mode is as an ES3
compatibility mode and ES3 has no generators, I consider this flagging
issue to be the important one. Yes, you have to read the function to know
*what* it
I get the point. Indeed. Modes are a kind of magic...
Regarding the secondary reason:
I don't understand the difference well, could you explain in detail?
You know, all other languages that are dynamically typed and have
generators, such as python, lua, and even JavaScript 1.8 don't
distinguish
On Sat, Aug 31, 2013 at 9:03 AM, Nathan Wall nathan.w...@live.com wrote:
Am I correct to understand that queue a microtask means that the task
should be run asynchronously? For this, I am currently using a function
called `defer(f)` which is just a wrapper around `setTimeout(f, 0)`.
Yes,
Microtasks are unfortunately not defined anywhere, but Anne has [a bug open on
HTML5][1] to do so.
Well, OK, looking at the spec, it kind of defines [something called a
microtask][2], but it's deeply coupled with the `MutationObserver` objects at
the moment.
[1]:
Ressurrecting this thread whoo :)
I don't feel static typing making its way to JavaScript. It just wouldn't
fit. The core libraries haven't been designed for it, and the community
libraries haven't been designated for it. I'd say static typing in JS is a
lost cause now. Designing a language for
Domenic Denicola mailto:dome...@domenicdenicola.com
August 31, 2013 2:17 PM
Microtasks are unfortunately not defined anywhere, but Anne has [a bug
open on HTML5][1] to do so.
Right, not defined.
Well, OK, looking at the spec, it kind of defines
kind of defines, more precisely stated as
Generators are a kind of factory function. When you call a generator,
you get an iterator with a bit of extra protocol (.throw as well as .next).
No big deal, lots of API contracts are implemented by functions, you say
-- why does this one deserve special head syntax. 'return' can be hard
to
Fwiw, just bikesheddingly speaking I actually prefer the *.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brian Kardell wrote:
Fwiw, just bikesheddingly speaking I actually prefer the *.
Let's review. Three reasons for function* syntax:
1. Opt-in required for backward-incompatible definition of 'yield' as
low-precedence unary prefix operator.
2. Zero-yield (no yield in body) basis case,
On Sat, Aug 31, 2013 at 2:12 PM, Yuichi Nishiwaki
yuichi.nishiw...@gmail.com wrote:
I get the point. Indeed. Modes are a kind of magic...
Regarding the secondary reason:
I don't understand the difference well, could you explain in detail?
function f() {
// code sequence 1
2013/9/1 Brendan Eich bren...@mozilla.com:
Generators are a kind of factory function. When you call a generator, you
get an iterator with a bit of extra protocol (.throw as well as .next).
No big deal, lots of API contracts are implemented by functions, you say --
why does this one deserve
On Aug 31, 2013, at 8:12 AM, Kalinni Gorzkis wrote:
Right now, please ask Ecma International to give me a Creative Commons
free-culture license (without NonCommercial nor NoDerivatives) so that I can
distribute the document to others with the same license.
You need to contact (
On Aug 31, 2013 6:20 PM, Brendan Eich bren...@mozilla.com wrote:
Brian Kardell wrote:
Fwiw, just bikesheddingly speaking I actually prefer the *.
Let's review. Three reasons for function* syntax:
1. Opt-in required for backward-incompatible definition of 'yield' as
low-precedence unary
You say the things get worse because introducing yields causes a probem
that another parameter -- when to call a certain code block -- might be
added at the time when readung the code, but I don't agree. There is
already a parameter for code reading: how many times the code will be
executed (or in
On Aug 31, 2013, at 3:19 PM, Brendan Eich wrote:
Brian Kardell wrote:
Fwiw, just bikesheddingly speaking I actually prefer the *.
Let's review. Three reasons for function* syntax:
1. Opt-in required for backward-incompatible definition of 'yield' as
low-precedence unary prefix
I hope you agree we are beating a dead horse, given my reasons #1 and 2
require function* -- just checking.
Yuichi Nishiwaki wrote:
2013/9/1 Brendan Eichbren...@mozilla.com:
Generators are a kind of factory function. When you call a generator, you
get an iterator with a bit of extra
Allen Wirfs-Brock wrote:
On Aug 31, 2013, at 3:19 PM, Brendan Eich wrote:
Brian Kardell wrote:
Fwiw, just bikesheddingly speaking I actually prefer the *.
Let's review. Three reasons for function* syntax:
1. Opt-in required for backward-incompatible definition of 'yield' as
Brendan Eich wrote:
A GeneratorFunction's body is evaluated sometime after its call
returns.
This is ill-stated. You mean a continuation of a yield in its body is
evaluated, not the whole body (re-)evaluated.
Of course, there may be no yield, or the yield may not be reached.
Yuichi
I think you miss my point, or I miss your's. I am not talking about how
many times the code runs or even whether the code runs at all. I thought I
made that clear. I am talking about whether the code in the callee
activation runs *after* the caller resumes.
Allen clearly and separately makes the
Allen Wirfs-Brock wrote:
It's starting off on the wrong foot to assume that Ecma is a money
grubby organization that is using copyright to enrich themselves (do
you know that if you ask, Ecma will send you, for no charge, a printed
and bound copy of any Ecma standard). Ecma's primary concerns
Yes, that is the call I mean as well.
On Sat, Aug 31, 2013 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote:
Brendan Eich wrote:
A GeneratorFunction's body is evaluated sometime after its call
returns.
This is ill-stated. You mean a continuation of a yield in its body is
evaluated,
Mark S. Miller wrote:
Brendan, your response to Allen I, citing Yuichi, misses this point
as well.
No, I get that point and ack'ed it to Allen:
A regular Function's body is evaluated before its call returns.
Yes, generators have an implicit yield; at the top. Now you have hit an
On Sun, Sep 1, 2013 at 2:43 AM, Brendan Eich bren...@mozilla.com wrote:
Lots of constructors/factories out there. An essential (see Aristotle)
argument for why function* for generator syntax (ignoring trumping reasons
12) must say why *this* particular factory needs special (a la function*)
I thought Id agreed to #1 and #2 but seems to have failed to communicate
that to you, Alright about 2 of them, thanks :)
On Sep 1, 2013 9:32 AM, Brendan Eich bren...@mozilla.com wrote:
I hope you agree we are beating a dead horse, given my reasons #1 and 2
require function* -- just checking.
I don't think I miss it, but the example I took was somohow bot clear. I
meant you can get to know if the code will run immediately or after the
habdle back, by reading the code in the same way as you do a normal
function.
On Sep 1, 2013 9:55 AM, Mark S. Miller erig...@google.com wrote:
I think
I know pretty well I’m probably not going to convince the believers here, but
this whole “we need an indication at the beginning of the function” thing is
kinda not making sense.
For starter, the generator function always starts at its first line. If what
you {Till Schneidereit} mean is that
On Sat, Aug 31, 2013 at 6:55 PM, François REMY
francois.remy@outlook.com wrote:
I know pretty well I’m probably not going to convince the believers here,
but this whole “we need an indication at the beginning of the function”
thing is kinda not making sense.
For starter, the generator
[...] The only contextual knowledge the reader
needs in order to know this is that there are no
intermediate function definitions within f
wrapping code sequence 2 -- i.e., that code
sequence 2 is code of the function f itself, as
opposed to code of a function within function a.
It
On Sat, Aug 31, 2013 at 8:34 PM, François REMY
francois.remy@outlook.com wrote:
[...] The only contextual knowledge the reader
needs in order to know this is that there are no
intermediate function definitions within f
wrapping code sequence 2 -- i.e., that code
sequence 2 is code
Till Schneidereit mailto:t...@tillschneidereit.net
August 31, 2013 6:05 PM
On Sun, Sep 1, 2013 at 2:43 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Lots of constructors/factories out there. An essential (see
Aristotle) argument for why function* for generator
The NoIn grammar productions have been removed in rev17. Does this mean
that `for (a in b;;);` is now a valid (C-style) for-loop instead of a
SyntaxError?
Thanks,
André
___
es-discuss mailing list
es-discuss@mozilla.org
Hello!
PROBLEM
In the present state of the spec, there is little inconsistency between
behaviour of new and super.
What these operation roughly do is:
new Foo(...args) is
Foo.call(Foo[@@create](), ...args)
super(...args) inside constructor is
Allen, are you doing this some other way? Static semantics can't do it,
we need parametric productions or else ye olde NoIn splitting.
/be
André Bargull mailto:andre.barg...@udo.edu
August 31, 2013 4:21 AM
The NoIn grammar productions have been removed in rev17. Does this
mean that `for (a in
I've come to learn the TC39 committee members
usually have good ideas even if they seem bad initially.
I hope this is the case again this time...
That is nice to hear, and quite a track record to live up to.
On behalf of all TC39 if I may, thanks.
Well, I don't think I deserve such
49 matches
Mail list logo
