Re: Questions/issues regarding generators
In the ideal (from my point of view) world, no object will have both an
iterator() and a next() method together (so Iterator and Iterable would be
different entities; the first having an internal state, and the second
stateless). So your example would be:
var iterable = getSomeIterable();
var i = it.iterator();
var x0 = i.next(), x1 = i.next(), x2 = i.next();
for (let x of iterable) { ... }
and 'for .. of', very clearly from this code, restarts iteration.
I can imagine the world where 'for .. of' iterates over iterators as well
(by calling their 'next()' method directly; so the spec would be if
iterator() exists, use it, otherwise if next() exists, use it). In this
world 'for(let x of i)' would continue a started iteration while 'for (let
x of iterable)' would start a new one.
I can also imagine the world where the iterator changes its nature - once
it is created, potentially an iterator and potentially an iterable. Once
you call next() on it, you've lost the ability to call an iterator() on it.
I think that would be the logical implication of cloning semantics. But the
more I think of it the more I feel that this way lies madness - so I guess
you are right and a sane cloning semantic does not exist.
Dmitry
On Thu, Mar 14, 2013 at 10:54 PM, Brendan Eich bren...@mozilla.com wrote:
Consider:
var i = getSomeIterator();
var x0 = i.next(), x1 = i.next(), x2 = i.next();
for (let x of i) {
...
}
Should the loop iterate over x0, x1, and x2? That's what would (have to)
happen if i[@iterator]() returned a cloneof the iterator ireset to the
starting position.
Of course the iteration protocol we have in Harmony has no notion of
position, or memory, or any particular thing that might be needed to replay
x0, x1, and x2.
Cloning i at its current position (if such a notion exists) has the
problem that Andreas objected to in the o.p.
Not cloning i, making iter[@iterator]() === iter as in Python, solves the
problem minimally.
I don't see a way to specify iterator cloning as part of the iteration
protocol. What am I missing?
/be
Dmitry Lomov wrote:
(I'll address comments from both your e-mails here)
On Tue, Mar 12, 2013 at 7:56 AM, Jason Orendorff
jason.orendo...@gmail.com
mailto:jason.orendorff@gmail.**comjason.orendo...@gmail.com
wrote:
On Tue, Mar 12, 2013 at 1:06 AM, Dmitry Lomov dslo...@google.com
mailto:dslo...@google.com wrote:
At a risk of repeating myself, 'open()' scenario is handled
perfectly well with the iterable (see my example). Example
where things truly cannot be reiterated (I am not sure why
network stream is such an example - the network connection can
always be opened twice) are rare. One possibility will be to
throw on the second call to iterator().
Gosh, maybe we are irreconcilable then. Implicitly opening network
connections many times seems bad to me. Same for reopening files,
actually.
I do not think we are irreconcilable. Clearly there is a library design
choice here. A designer of a particular library for file/network IO may or
may not consider opening a file on 'iterator()' call too implicit. I think
it is not too implicit, while you appear to think otherwise.
In the world with Iterables, the library designer can easily disallow
iterating the result of open a second time - as I suggested above, if for
whatever reason the sequence cannot be re-iterated, iterator() method can
throw on second call. In that case, attempt to zip a file with itself will
throw when zip calls the iterator method a second time, and that will be an
early failure with a clear cause.
However, non-reiterable iterables are a fringe case - maybe 10% of
iterators are non-re-iterable even by the standards you suggest (expensive
operations on iteration start). [I am being generous here; seems that all
allegedly non-reiterable examples suggested so far has been related to I/O;
given that I/O libraries are generally asynchronous in ES, I/O is generally
not very amenable to be implemented as iterators, since in general results
of I/O operations are only available in a callback, and not on-demand, as
next() method would require]. My educated guess would be that 90%
iterators/iterables in the wild would be easily re-iterable, as they would
be results of operations over collections (such as filter, map, zip and
similar). This is a baby that gets thrown with the water, not the
non-restartable iterators
This semantics is sound and consistent, but there is a problem: by
that logic, the first call 'zip(rangeAsArray, rangeAsArray)' also
has all the appearances of a user error! It requires careful
analysis and thinking to convince oneself that it is indeed
correct. Well, maybe not in a simple case when the initializer of
rangeAsArray is an array literal, but as soon as the initializer
is more complicated - say an external
Re: Questions/issues regarding generators
On Mar 14, 2013, at 8:01 PM, Andreas Rossberg rossb...@google.com wrote: Yes. Iterators have a next method, that's all what makes them an iterator, according to the wiki, and having an iterator method is never mentioned there. It's mentioned on the iterators proposal page as Iterator.prototype.iterator. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module Loader Comments
Anyway, my questions are cleared up (for now). Can't wait for those wiki
updates! ; )
Ah - one more comment.
The signatures for `load` and `evalAsync` indicate that they will return
`this`, a reference to the loader. These functions are prime candidates
for returning futures (e.g. something with a `then` method) in some future
version of ES with standardized promises/futures. Would it be more
future-safe to leave the return values of these methods `undefined` for the
present?
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
We discussed the factoring of the generator object model at the Nov 27
meeting. In the notes
https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-11/nov-27.md there is
a sketch of the hierarchy we agreed to:
https://dl.dropbox.com/u/3531958/tc39/generator-diagram-1.jpg
The design Andy referenced is one I presented at the meeting. It is very close
to but not identical to the that sketched in the above linked whiteboard
diagram.
But most JS developers won't need to think about this at all. They just
defined generator constructors using generator expressions or function*
declarations and then either implicitly (generator expressions) or explicitly
call them to get generator instance. However, there are edge cases and
consistency issues where the actual object model becomes visible and is need
to explain the most reasonable behavior. For example consider:
function *Interval(start, end) {
for (;start=end;start++) yield start;
}
let i1 = Interval(1,10);
let i2 = Interval(20,10);
It seems most consistent with JavaScript conventions that:
console.log(i1 instanceof Interval); //true
console.log(i1.constructor === i2.constructor); //true
console.log(i2.constructor === Interval); //true
console.log(Object.getPrototypeOf(i2) === i2.constructor.prototype);
Also i1 and i2 essentially share common implementations of the
next,send,throw,close methods that are derived from the body of the Interval
generator definition. It makes sense for all instances of Interval to share
those methods rather than replicating them as own methods. This suggests that
they belong in a common prototype object.
At the Nov meeting we discussed all these things (and others) and there was
fairly strong consensus that this sort of design was needed for provide a
plausible meta foundation for explaining and understanding how generators fit
with the rest of ES. That basically matched my personal experience. I
originally created various forms (I think I showed 4 alternatives at the
meeting) of that class hierarchy diagram to understand what function *(){}
was actually doing so I could spec. it adequately. Once I had the full
abstraction worked out in this manner. everything became quite clear.
I acknowledge that SpiderMonkey has had generators without worrying about such
details. To me that simply reflects the difference between the expectations
for an initial feature-functionality focused implementation and what we need to
do as part of a standard. Spider Monkey could get away with a more ad hoc
design that didn't worry too much about edge cases but as part of a standard
that is going to have multiple implementations and needs to support future
language evolution it is important that we work through these details and to
try to get it right.
Regarding new Interval(1,10). People don't need to say that (although I don't
think there is anything wrong with thinking about it that way) and if we want
to we can make it illegal. However, I think it is extra
design/spec/implementation work to disallow it and it seems like an arbitrary
restriction.
My intent for the near future is to take the consensus whiteboard design from
the Nov. 27 meeting and use it as the basis for what goes into the next ES6
draft.
Allen
On Mar 12, 2013, at 10:42 AM, Brendan Eich wrote:
This is not what we prototyped and shipped in SpiderMonkey starting in 2006,
and Rhino and probably other engines cloned, for years. That's not to say we
should or shouldn't do it, but I'm always leery of made-up stuff without any
prototype-implementation mileage.
Allen, is there any reason to make things more nested, with hidden
(Generator) constructor? I see what you're getting at but the lack of it has
never been an issue for JS1.7+ users. When in doubt, flat is better than
nested (Zen of Python).
/be
Andy Wingo wrote:
Hi,
Given function* g() { yield 1; }, are these equivalent?
new g();
g();
Somehow I had assumed that /calling/ would be the normal way to
instantiate a generator, but I see new in
http://wiki.ecmascript.org/doku.php?id=meetings:proposed_generator_class_hierarcy_nov_2013.png.
Thanks,
Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
I would prefer having to use `new` (but don’t have strong feelings about it):
generators are more like constructors than like functions. When I first started
experimenting with them in Firefox, it took me a while to figure that out (even
though it is obvious in hindsight). With `new`, I’d probably have figured it
out quicker.
Axel
On Mar 15, 2013, at 19:08 , Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We discussed the factoring of the generator object model at the Nov 27
meeting. In the notes
https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-11/nov-27.md there
is a sketch of the hierarchy we agreed to:
https://dl.dropbox.com/u/3531958/tc39/generator-diagram-1.jpg
The design Andy referenced is one I presented at the meeting. It is very
close to but not identical to the that sketched in the above linked
whiteboard diagram.
But most JS developers won't need to think about this at all. They just
defined generator constructors using generator expressions or function*
declarations and then either implicitly (generator expressions) or explicitly
call them to get generator instance. However, there are edge cases and
consistency issues where the actual object model becomes visible and is need
to explain the most reasonable behavior. For example consider:
function *Interval(start, end) {
for (;start=end;start++) yield start;
}
let i1 = Interval(1,10);
let i2 = Interval(20,10);
It seems most consistent with JavaScript conventions that:
console.log(i1 instanceof Interval); //true
console.log(i1.constructor === i2.constructor); //true
console.log(i2.constructor === Interval); //true
console.log(Object.getPrototypeOf(i2) === i2.constructor.prototype);
Also i1 and i2 essentially share common implementations of the
next,send,throw,close methods that are derived from the body of the Interval
generator definition. It makes sense for all instances of Interval to share
those methods rather than replicating them as own methods. This suggests
that they belong in a common prototype object.
At the Nov meeting we discussed all these things (and others) and there was
fairly strong consensus that this sort of design was needed for provide a
plausible meta foundation for explaining and understanding how generators fit
with the rest of ES. That basically matched my personal experience. I
originally created various forms (I think I showed 4 alternatives at the
meeting) of that class hierarchy diagram to understand what function *(){}
was actually doing so I could spec. it adequately. Once I had the full
abstraction worked out in this manner. everything became quite clear.
I acknowledge that SpiderMonkey has had generators without worrying about
such details. To me that simply reflects the difference between the
expectations for an initial feature-functionality focused implementation and
what we need to do as part of a standard. Spider Monkey could get away with
a more ad hoc design that didn't worry too much about edge cases but as part
of a standard that is going to have multiple implementations and needs to
support future language evolution it is important that we work through these
details and to try to get it right.
Regarding new Interval(1,10). People don't need to say that (although I
don't think there is anything wrong with thinking about it that way) and if
we want to we can make it illegal. However, I think it is extra
design/spec/implementation work to disallow it and it seems like an arbitrary
restriction.
My intent for the near future is to take the consensus whiteboard design from
the Nov. 27 meeting and use it as the basis for what goes into the next ES6
draft.
Allen
On Mar 12, 2013, at 10:42 AM, Brendan Eich wrote:
This is not what we prototyped and shipped in SpiderMonkey starting in 2006,
and Rhino and probably other engines cloned, for years. That's not to say we
should or shouldn't do it, but I'm always leery of made-up stuff without any
prototype-implementation mileage.
Allen, is there any reason to make things more nested, with hidden
(Generator) constructor? I see what you're getting at but the lack of it has
never been an issue for JS1.7+ users. When in doubt, flat is better than
nested (Zen of Python).
/be
Andy Wingo wrote:
Hi,
Given function* g() { yield 1; }, are these equivalent?
new g();
g();
Somehow I had assumed that /calling/ would be the normal way to
instantiate a generator, but I see new in
http://wiki.ecmascript.org/doku.php?id=meetings:proposed_generator_class_hierarcy_nov_2013.png.
Thanks,
Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
Re: Date.parse() sematics / internationalization
On Mar 14, 2013, at 3:20 AM, Paul Ruizendaal wrote: There seems to be ambiguity over the semantics of Date.parse() in the spec (both 5.1 and latest 6 draft). The spec says: The String may be interpreted as a local time, a UTC time, or a time in some other time zone, depending on the contents of the String. Note that it doesn't say depending on the implementation. But the next two sentences say: The function first attempts to parse the format of the String according to the rules called out in Date Time String Format (15.9.1.15). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats. (italics added) In a quick test of Date.parse(1970T23:35:22) I got the following results: - Chrome: UTC time - Firefox: local time - IE9: UTC time - Safari: fails on this pattern, but Thu Jan 1 1970 23:35:22 gets interpreted as local time Section 15.9.1.15 does not seem to specify when to interpret the string as local and when UTC. In my reading it is implied that a string is interpreted as local unless a time zone specifier is added (possibly UTC+00:00). However this seems to be at odds with the interpretation at MS/Google, and I must admit that interpretation as UTC seemed logical to me before I got deeply into this. see https://bugs.ecmascript.org/show_bug.cgi?id=112 https://bugs.ecmascript.org/show_bug.cgi?id=342 There is no test for this in test262. Moreover, test262 is currently badly broken on timezone handling with the timezone hardcoded to California Summer time (see bug 293 and 330). The earlier Sputnik code got it mostly right for folks all around the globe but was of by a week with DST start/stop time in California. I would recommend that the hardcoding is backed out again and that timezone handling reverts to the Sputnik timezone logic (Dave Fugate left MS shortly after doing the hardcoding -- I guess he never got around to doing a proper fix). With that in place, writing tests for Date.parse() semantics is trivial and I'm happy to contribute. You should file test262 bugs, if you haven't already. Paul ___ test262-discuss mailing list test262-disc...@mozilla.org https://mail.mozilla.org/listinfo/test262-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
On Mar 15, 2013, at 11:22 AM, Axel Rauschmayer wrote:
I would prefer having to use `new` (but don’t have strong feelings about it):
generators are more like constructors than like functions. When I first
started experimenting with them in Firefox, it took me a while to figure that
out (even though it is obvious in hindsight). With `new`, I’d probably have
figured it out quicker.
My experience was similar.
Allen
Axel
On Mar 15, 2013, at 19:08 , Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We discussed the factoring of the generator object model at the Nov 27
meeting. In the notes
https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-11/nov-27.md there
is a sketch of the hierarchy we agreed to:
https://dl.dropbox.com/u/3531958/tc39/generator-diagram-1.jpg
The design Andy referenced is one I presented at the meeting. It is very
close to but not identical to the that sketched in the above linked
whiteboard diagram.
But most JS developers won't need to think about this at all. They just
defined generator constructors using generator expressions or function*
declarations and then either implicitly (generator expressions) or
explicitly call them to get generator instance. However, there are edge
cases and consistency issues where the actual object model becomes visible
and is need to explain the most reasonable behavior. For example consider:
function *Interval(start, end) {
for (;start=end;start++) yield start;
}
let i1 = Interval(1,10);
let i2 = Interval(20,10);
It seems most consistent with JavaScript conventions that:
console.log(i1 instanceof Interval); //true
console.log(i1.constructor === i2.constructor); //true
console.log(i2.constructor === Interval); //true
console.log(Object.getPrototypeOf(i2) === i2.constructor.prototype);
Also i1 and i2 essentially share common implementations of the
next,send,throw,close methods that are derived from the body of the Interval
generator definition. It makes sense for all instances of Interval to share
those methods rather than replicating them as own methods. This suggests
that they belong in a common prototype object.
At the Nov meeting we discussed all these things (and others) and there was
fairly strong consensus that this sort of design was needed for provide a
plausible meta foundation for explaining and understanding how generators
fit with the rest of ES. That basically matched my personal experience. I
originally created various forms (I think I showed 4 alternatives at the
meeting) of that class hierarchy diagram to understand what function *(){}
was actually doing so I could spec. it adequately. Once I had the full
abstraction worked out in this manner. everything became quite clear.
I acknowledge that SpiderMonkey has had generators without worrying about
such details. To me that simply reflects the difference between the
expectations for an initial feature-functionality focused implementation and
what we need to do as part of a standard. Spider Monkey could get away with
a more ad hoc design that didn't worry too much about edge cases but as part
of a standard that is going to have multiple implementations and needs to
support future language evolution it is important that we work through these
details and to try to get it right.
Regarding new Interval(1,10). People don't need to say that (although I
don't think there is anything wrong with thinking about it that way) and if
we want to we can make it illegal. However, I think it is extra
design/spec/implementation work to disallow it and it seems like an
arbitrary restriction.
My intent for the near future is to take the consensus whiteboard design
from the Nov. 27 meeting and use it as the basis for what goes into the next
ES6 draft.
Allen
On Mar 12, 2013, at 10:42 AM, Brendan Eich wrote:
This is not what we prototyped and shipped in SpiderMonkey starting in
2006, and Rhino and probably other engines cloned, for years. That's not to
say we should or shouldn't do it, but I'm always leery of made-up stuff
without any prototype-implementation mileage.
Allen, is there any reason to make things more nested, with hidden
(Generator) constructor? I see what you're getting at but the lack of it
has never been an issue for JS1.7+ users. When in doubt, flat is better
than nested (Zen of Python).
/be
Andy Wingo wrote:
Hi,
Given function* g() { yield 1; }, are these equivalent?
new g();
g();
Somehow I had assumed that /calling/ would be the normal way to
instantiate a generator, but I see new in
http://wiki.ecmascript.org/doku.php?id=meetings:proposed_generator_class_hierarcy_nov_2013.png.
Thanks,
Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
Re: instantiating generators
On 3/15/2013 11:51 AM, Allen Wirfs-Brock wrote: On Mar 15, 2013, at 11:22 AM, Axel Rauschmayer wrote: I would prefer having to use `new` (but don't have strong feelings about it): generators are more like constructors than like functions. When I first started experimenting with them in Firefox, it took me a while to figure that out (even though it is obvious in hindsight). With `new`, I'd probably have figured it out quicker. My experience was similar. Mine was as well. Admittedly it's kind of odd to use something like `new obj.method` but it does more accurately describe what it was going on. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
Ah, methods are more tricky! Then you have `this` to contend with. On Mar 15, 2013, at 20:02 , Brandon Benvie bben...@mozilla.com wrote: On 3/15/2013 11:51 AM, Allen Wirfs-Brock wrote: On Mar 15, 2013, at 11:22 AM, Axel Rauschmayer wrote: I would prefer having to use `new` (but don’t have strong feelings about it): generators are more like constructors than like functions. When I first started experimenting with them in Firefox, it took me a while to figure that out (even though it is obvious in hindsight). With `new`, I’d probably have figured it out quicker. My experience was similar. Mine was as well. Admittedly it's kind of odd to use something like `new obj.method` but it does more accurately describe what it was going on. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
Yeah but since the generator holds the initial |this| for its lifetime you can treat it kind of like a bound function. On Mar 15, 2013, at 12:41 PM, Axel Rauschmayer a...@rauschma.de wrote: Ah, methods are more tricky! Then you have `this` to contend with. On Mar 15, 2013, at 20:02 , Brandon Benvie bben...@mozilla.com wrote: On 3/15/2013 11:51 AM, Allen Wirfs-Brock wrote: On Mar 15, 2013, at 11:22 AM, Axel Rauschmayer wrote: I would prefer having to use `new` (but don’t have strong feelings about it): generators are more like constructors than like functions. When I first started experimenting with them in Firefox, it took me a while to figure that out (even though it is obvious in hindsight). With `new`, I’d probably have figured it out quicker. My experience was similar. Mine was as well. Admittedly it's kind of odd to use something like `new obj.method` but it does more accurately describe what it was going on. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
On Fri, Mar 15, 2013 at 11:51 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Mar 15, 2013, at 11:22 AM, Axel Rauschmayer wrote:
I would prefer having to use `new` (but don’t have strong feelings about
it): generators are more like constructors than like functions. When I first
started experimenting with them in Firefox, it took me a while to figure
that out (even though it is obvious in hindsight). With `new`, I’d probably
have figured it out quicker.
My experience was similar.
Mine's the opposite - my experience with generators in Python built up
a strong and very natural-feeling intuition that a generator was just
a function that returned a magic list. Trying to push that into a
constructor notion would feel awkward.
Actually using it would be even more awkward than thinking about it, I
believe. For example, I use the enumerate() generator *all the time*
in Python. Having to always write:
for(x of new enumerate(seq)) {...}
would feel really weird, even if you changed the conjugation of the
function to enumeration().
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
On Mar 15, 2013, at 1:18 PM, Tab Atkins Jr. wrote:
On Fri, Mar 15, 2013 at 11:51 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Mar 15, 2013, at 11:22 AM, Axel Rauschmayer wrote:
I would prefer having to use `new` (but don’t have strong feelings about
it): generators are more like constructors than like functions. When I first
started experimenting with them in Firefox, it took me a while to figure
that out (even though it is obvious in hindsight). With `new`, I’d probably
have figured it out quicker.
My experience was similar.
Mine's the opposite - my experience with generators in Python built up
a strong and very natural-feeling intuition that a generator was just
a function that returned a magic list. Trying to push that into a
constructor notion would feel awkward.
Actually using it would be even more awkward than thinking about it, I
believe. For example, I use the enumerate() generator *all the time*
in Python. Having to always write:
for(x of new enumerate(seq)) {...}
would feel really weird, even if you changed the conjugation of the
function to enumeration().
Agree that requiring new would be ackward. But permitting it seems reasonable.
Allen
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
for what is worth it, agreed with Tab Atkins here ... `new` does not
improve much semantically speaking, it's actually just confusing, IMHO
On Fri, Mar 15, 2013 at 1:18 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Mar 15, 2013 at 11:51 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Mar 15, 2013, at 11:22 AM, Axel Rauschmayer wrote:
I would prefer having to use `new` (but don’t have strong feelings about
it): generators are more like constructors than like functions. When I
first
started experimenting with them in Firefox, it took me a while to figure
that out (even though it is obvious in hindsight). With `new`, I’d
probably
have figured it out quicker.
My experience was similar.
Mine's the opposite - my experience with generators in Python built up
a strong and very natural-feeling intuition that a generator was just
a function that returned a magic list. Trying to push that into a
constructor notion would feel awkward.
Actually using it would be even more awkward than thinking about it, I
believe. For example, I use the enumerate() generator *all the time*
in Python. Having to always write:
for(x of new enumerate(seq)) {...}
would feel really weird, even if you changed the conjugation of the
function to enumeration().
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
On Fri, Mar 15, 2013 at 1:22 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Agree that requiring new would be ackward. But permitting it seems reasonable. Yeah, I see no value in making new invalid. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
Tab Atkins Jr. wrote:
On Fri, Mar 15, 2013 at 11:51 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Mar 15, 2013, at 11:22 AM, Axel Rauschmayer wrote:
I would prefer having to use `new` (but don’t have strong feelings about
it): generators are more like constructors than like functions. When I first
started experimenting with them in Firefox, it took me a while to figure
that out (even though it is obvious in hindsight). With `new`, I’d probably
have figured it out quicker.
My experience was similar.
Mine's the opposite - my experience with generators in Python built up
a strong and very natural-feeling intuition that a generator was just
a function that returned a magic list. Trying to push that into a
constructor notion would feel awkward.
Actually using it would be even more awkward than thinking about it, I
believe. For example, I use the enumerate() generator *all the time*
in Python. Having to always write:
for(x of new enumerate(seq)) {...}
would feel really weird, even if you changed the conjugation of the
function to enumeration().
Don't worry, we are not going to require 'new'.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
but then the direction is a bit inconsistent since native constructors are
going to require `new
On Fri, Mar 15, 2013 at 1:36 PM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
On Fri, Mar 15, 2013 at 11:51 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Mar 15, 2013, at 11:22 AM, Axel Rauschmayer wrote:
I would prefer having to use `new` (but don’t have strong feelings about
it): generators are more like constructors than like functions. When I
first
started experimenting with them in Firefox, it took me a while to figure
that out (even though it is obvious in hindsight). With `new`, I’d
probably
have figured it out quicker.
My experience was similar.
Mine's the opposite - my experience with generators in Python built up
a strong and very natural-feeling intuition that a generator was just
a function that returned a magic list. Trying to push that into a
constructor notion would feel awkward.
Actually using it would be even more awkward than thinking about it, I
believe. For example, I use the enumerate() generator *all the time*
in Python. Having to always write:
for(x of new enumerate(seq)) {...}
would feel really weird, even if you changed the conjugation of the
function to enumeration().
Don't worry, we are not going to require 'new'.
/be
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
(sorry, I sent by accident) I meant native requires `new` and there is
already a subset, generators, that are flexible as native constructors are
now (e.g. Object() instead of new Object())
anyway, better than mandatory `new` so ...
On Fri, Mar 15, 2013 at 1:59 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
but then the direction is a bit inconsistent since native constructors are
going to require `new
On Fri, Mar 15, 2013 at 1:36 PM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
On Fri, Mar 15, 2013 at 11:51 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Mar 15, 2013, at 11:22 AM, Axel Rauschmayer wrote:
I would prefer having to use `new` (but don’t have strong feelings
about
it): generators are more like constructors than like functions. When I
first
started experimenting with them in Firefox, it took me a while to
figure
that out (even though it is obvious in hindsight). With `new`, I’d
probably
have figured it out quicker.
My experience was similar.
Mine's the opposite - my experience with generators in Python built up
a strong and very natural-feeling intuition that a generator was just
a function that returned a magic list. Trying to push that into a
constructor notion would feel awkward.
Actually using it would be even more awkward than thinking about it, I
believe. For example, I use the enumerate() generator *all the time*
in Python. Having to always write:
for(x of new enumerate(seq)) {...}
would feel really weird, even if you changed the conjugation of the
function to enumeration().
Don't worry, we are not going to require 'new'.
/be
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module Loader Comments
That sounds reasonable to me.
Dave
On Mar 15, 2013, at 11:01 AM, Kevin Smith khs4...@gmail.com wrote:
Anyway, my questions are cleared up (for now). Can't wait for those wiki
updates! ; )
Ah - one more comment.
The signatures for `load` and `evalAsync` indicate that they will return
`this`, a reference to the loader. These functions are prime candidates for
returning futures (e.g. something with a `then` method) in some future
version of ES with standardized promises/futures. Would it be more
future-safe to leave the return values of these methods `undefined` for the
present?
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
I don't know what you meant below in the first paragraph, but I'm going to assume you agree that 'new' should not be required for generators. :-|. /be Andrea Giammarchi wrote: (sorry, I sent by accident) I meant native requires `new` and there is already a subset, generators, that are flexible as native constructors are now (e.g. Object() instead of new Object()) anyway, better than mandatory `new` so ... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
On Fri, Mar 15, 2013 at 11:22 AM, Axel Rauschmayer a...@rauschma.de wrote: I would prefer having to use `new` (but don’t have strong feelings about it): generators are more like constructors than like functions. When I first started experimenting with them in Firefox, it took me a while to figure that out (even though it is obvious in hindsight). With `new`, I’d probably have figured it out quicker. I agree with Tab: I wonder if your mental model for generators might not continue to evolve. I would hate to have to write: for (k of new tree.preorder()) rather than: for (k of tree.preorder()) -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Where is it specified that new objects are empty, if it is?
I'm doing a little maintenance on SES. Chrome has recently added a new
odd behavior:
var o = Object.create(null);
Object.getOwnPropertyNames(o)
[]
Object.getOwnPropertyDescriptor(o, '__proto__');
Object {value: null, writable: true, enumerable: false, configurable: false}
The two results are clearly non-conformant, in that gOPN and gOPD
should be consistent with each other. However, the problem that I'm
wanting to record accurately is the fact that Object.create(null) has
(however inconsistently) any properties at all (thus interfering with
table-like uses).
15.2.3.5 Object.create refers to 15.2.2.1 which specifies “a newly
created native ECMAScript object”. Where is the initial state of the
collection of properties of a “newly created” object specified? (8.6
defining the Object type doesn't say anything about the existence of
non-internal properties.)
(I recognize that this behavior may well be a deliberate variance to
reconcile __proto__ and ES5/ES6. This is not a complaint; this is a
request to consult spec-lawyers.)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Where is it specified that new objects are empty, if it is?
Kevin Reid wrote:
I'm doing a little maintenance on SES. Chrome has recently added a new
odd behavior:
var o = Object.create(null);
Object.getOwnPropertyNames(o)
[]
Object.getOwnPropertyDescriptor(o, '__proto__');
Object {value: null, writable: true, enumerable: false, configurable: false}
Oh come on! :-P
The two results are clearly non-conformant, in that gOPN and gOPD
should be consistent with each other. However, the problem that I'm
wanting to record accurately is the fact that Object.create(null) has
(however inconsistently) any properties at all (thus interfering with
table-like uses).
ES6 will specify __proto__ as own and configurable in
Object.prototype. Whether magic data or accessor with censored or
poisoned getter and setter I'm not sure at the moment, but the above
will definitely not conform to ES6.
15.2.3.5 Object.create refers to 15.2.2.1 which specifies “a newly
created native ECMAScript object”. Where is the initial state of the
collection of properties of a “newly created” object specified? (8.6
defining the Object type doesn't say anything about the existence of
non-internal properties.)
Whoa, spec hole. Allen?
(I recognize that this behavior may well be a deliberate variance to
reconcile __proto__ and ES5/ES6. This is not a complaint; this is a
request to consult spec-lawyers.)
Ok, whew. Sorry for lawyering,
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Questions/issues regarding generators
On 03/14/2013 04:14 PM, Brendan Eich wrote:
Andreas Rossberg wrote:
On 14 March 2013 23:38, Brendan Eichbren...@mozilla.com wrote:
Andreas Rossberg wrote:
That leaves my original proposal not to have generator application
return an iterator, but only an iterable. Under that proposal, your
example requires disambiguation by inserting the intended call(s) to
.iterator in the right place(s).
That's horribly inconvenient. It takes Dmitry's example:
function* enum(from, to) { for (let i = from; i= to; ++i) yield i }
let rangeAsGenerator = enum(1, 4)
let dup = zip(rangeAsGenerator, rangeAsGenerator) // Oops!
which contains a bug under the Harmony proposal, to this:
function* enum(from, to) { for (let i = from; i= to; ++i) yield i }
let rangeAsGenerator = enum(1, 4)
let dup = zip(rangeAsGenerator[@iterator](), rangeAsGenerator[@iterator]())
No, why? The zip function invokes the iterator method for you.
Sure, but only if you know that. I thought you were advocating explicit
iterator calls.
A call expression cannot be assumed to return a result that can be consumed by
some mutating protocol twice, in general. Why should generator functions be
special?
I agree they could be special-cased, but doing so requires an extra allocation
(the generator-iterable that's returned).
Meanwhile the Pythonic pattern is well-understood, works fine, and (contra
Dmitry's speculation) does not depend on class-y OOP in Python.
I guess it's the season of extra allocations, but still: in general when I
consume foo() via something that mutates its return value, I do not expect to
be able to treat foo() as referentially transparent. Not in JS!
Does for-of accept only iterables, only iterators, or both? Presumably a function like
zip would make a similar decision. The problem is if the answer is both.
Waldemar
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
I agree on that and on top I would rather throw if `new` is used ... but I understand on being permissive, is just weird `Object()` instead of `new Object()` won't be accepted anymore, but for generators there is such exception. This is all I was trying to say. On Fri, Mar 15, 2013 at 3:48 PM, Brendan Eich bren...@mozilla.com wrote: I don't know what you meant below in the first paragraph, but I'm going to assume you agree that 'new' should not be required for generators. :-|. /be Andrea Giammarchi wrote: (sorry, I sent by accident) I meant native requires `new` and there is already a subset, generators, that are flexible as native constructors are now (e.g. Object() instead of new Object()) anyway, better than mandatory `new` so ... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Where is it specified that new objects are empty, if it is?
V8 now uses an accessor on Object.prototype.
On Mar 15, 2013 7:20 PM, Brendan Eich bren...@mozilla.com wrote:
Kevin Reid wrote:
I'm doing a little maintenance on SES. Chrome has recently added a new
odd behavior:
var o = Object.create(null);
Object.getOwnPropertyNames(o)
[]
Object.**getOwnPropertyDescriptor(o, '__proto__');
Object {value: null, writable: true, enumerable: false, configurable:
false}
Oh come on! :-P
The two results are clearly non-conformant, in that gOPN and gOPD
should be consistent with each other. However, the problem that I'm
wanting to record accurately is the fact that Object.create(null) has
(however inconsistently) any properties at all (thus interfering with
table-like uses).
ES6 will specify __proto__ as own and configurable in Object.prototype.
Whether magic data or accessor with censored or poisoned getter and setter
I'm not sure at the moment, but the above will definitely not conform to
ES6.
15.2.3.5 Object.create refers to 15.2.2.1 which specifies “a newly
created native ECMAScript object”. Where is the initial state of the
collection of properties of a “newly created” object specified? (8.6
defining the Object type doesn't say anything about the existence of
non-internal properties.)
Whoa, spec hole. Allen?
(I recognize that this behavior may well be a deliberate variance to
reconcile __proto__ and ES5/ES6. This is not a complaint; this is a
request to consult spec-lawyers.)
Ok, whew. Sorry for lawyering,
/be
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
On Fri, Mar 15, 2013 at 11:22 AM, Axel Rauschmayer a...@rauschma.de wrote: I would prefer having to use `new` (but don’t have strong feelings about it): generators are more like constructors than like functions. When I first started experimenting with them in Firefox, it took me a while to figure that out (even though it is obvious in hindsight). With `new`, I’d probably have figured it out quicker. I agree with Tab: I wonder if your mental model for generators might not continue to evolve. I would hate to have to write: for (k of new tree.preorder()) rather than: for (k of tree.preorder()) Yes, it will probably evolve. The wish for `new` comes up if you know what’s inside a generator function and are surprised that you need to invoke a method to start executing the function body. If you treat it as a black box then `new` makes less sense, then it is roughly a function or method that returns an iterator. (Tongue in cheek, you could argue that Python does treat generators like classes) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: instantiating generators
Andrea Giammarchi wrote: I agree on that and on top I would rather throw if `new` is used ... That might be ok. The newborn passed in as this could be returned via first yield, though, so while it's an odd thing to take advantage of, the semantics of new and function* combine without harm. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
