TC39 Delegates
2022-07-07
plaintext logs
prev next
source on github
15:04
<zbraniecki>
Can you explain what are the tangible implications of choosing Iterator here?
15:31
<rbuckton (OOF: 7/5 - 7/16)>

šŸ‘€ I want to do a temperature check on the range proposal (discussion https://github.com/tc39/proposal-Number.range/issues/17 )

Do you think it should be a Iterator (1ļøāƒ£) or an Iterable object (šŸ”¢)?

I generally prefer Iterable, so that a range can be reused:

const oneToTen = Number.range(1, 10);
// prints: 1\n2\n...
for (const x of oneToTen) console.log(x);
// prints: ??? 
for (const x of oneToTen) console.log(x);

Its rare that someone will manually step through an iterator rather than use for..of or ..., and the latter will exhaust the iterator, making a range useless after it has been used once.
If you need to step over it manually, you could still use Symbol.iterator, so Iterable is vastly more flexible.
That said, the iterator helpers proposal depends on Iterator (which I still disagree with in principle), but relevant methods could be lifted to a Range as well.
I'm still hoping we could someday have a standalone range/slice syntax like a..b, though that can (hopefully) come later.

15:34
<rbuckton (OOF: 7/5 - 7/16)>
(and I am not very good at avoiding work when I'm supposed to be on PTO)
16:58
<ljharb>
you can reuse it by sticking ()=> in front of it
17:05
<rbuckton (OOF: 7/5 - 7/16)>
That's not reuse, that's recreating it each time. It also potentially reevaluates each argument, which could have side effects/performance implications.
17:07
<rbuckton (OOF: 7/5 - 7/16)>
i.e., const r = () => Number.range(0, f()). Beginners could easily overlook the f()
17:09
<rbuckton (OOF: 7/5 - 7/16)>
Maybe PFA could help, but it's also not something a beginner would likely reach for immediately, nor is the () => trick
17:14
<zbraniecki>
My mental model is aligned with rbuckton (PTO: 7/5 - 7/16) - oneToTen should produce an iterator when used in a loop. I probably am projecting how Rust does it where Range implements IntoIterator
17:20
<ljharb>
i don't think beginners will expect to reuse it either tho.
17:37
<rbuckton (PTO: 7/5 - 7/16)>
I think beginners are more likely to reuse it than not, just as you could reuse an array, or map, or set, or typed array. This is especially true if we do ever have a range/slice syntax in the future.
17:41
<rbuckton (PTO: 7/5 - 7/16)>
I'm still of the opinion that the iterator helpers proposal has a very short-sighted view by focusing on Iterator and not Iterable, and I'd rather not repeat the mistake of leveraging the wrong level of abstraction in more places if we can potentially avoid it. That said, Iterator is probably fine for Number.range() on its own, but I would be strongly opposed to the same behavior for any potential Range/slice syntax in the future.
17:57
<bakkot>
sidebar: I am now ~half of the agenda items for the next meeting. hope everyone is prepared to talk about dumb corner cases for an entire meeting.
18:08
<shu>
please cover them on wednesday, when i cannot be there
18:32
<ljharb>
iterable isnā€™t a thing, itā€™s a trait.
18:32
<ljharb>
whereas an iterator is a thing
19:37
<ptomato>
sidebar: I am now ~half of the agenda items for the next meeting. hope everyone is prepared to talk about dumb corner cases for an entire meeting.
I will add an item on Temporal, but unfortunately it's also all dumb corner cases
19:56
<littledan>
Are people thinking of breakout sessions for the upcoming TC39 meeting, given our possibly somewhat light schedule when finally meeting partly in person/hybrid?
19:58
<littledan>
I could imagine one breakout session on modules, one on inclusion, and maybe one on Ecma, if people are interested. I imagine that other people may have other interesting topics.
20:00
<jschoi>
(For what itā€™s worth, I am still planning to add along with Hemanth H.M three agenda items for a once function, a memoize function, and built-in cache maps/sets, so the agenda will fill up a little more than it is now. I might also fill in more time with some chartered incubator topics that havenā€™t yet had their incubator meetings, like Array.fromAsync, BigInt Math, bind-this and pipe/topic. Iā€™m not sure whether those would be more appropriate as breakout sessions or as ordinary agenda topics.)
20:01
<littledan>
oh yes please keep adding agenda items! those definitely are higher priority than the open-ended discussions I was suggesting.
20:02
<jschoi>
Some of the incubator topics are, for better or for worse, open-ended, especially discussion regarding dataflow syntaxes (including pipe/topic and bind-this). Also, I didnā€™t get to mention this at last plenary, but itā€™s good to see you again; hope you had a good past year.
20:02
<littledan>
yeah good to see you too!
20:02
<littledan>
I'd suggest that overflow incubator items could be breakout sessions, rather than agenda items
20:03
<littledan>
(I mean, unless someone really does want to present a proposal for them)
20:07
<littledan>
(For what itā€™s worth, I am still planning to add along with Hemanth H.M three agenda items for a once function, a memoize function, and built-in cache maps/sets, so the agenda will fill up a little more than it is now. I might also fill in more time with some chartered incubator topics that havenā€™t yet had their incubator meetings, like Array.fromAsync, BigInt Math, bind-this and pipe/topic. Iā€™m not sure whether those would be more appropriate as breakout sessions or as ordinary agenda topics.)
those new proposals sound interesting! they seem like tricky things to make built-in since caches/memoization sometimes have domain-specific retention policies; are you proposing hooks for those?
20:07
<jschoi>
As champion / co-champion of four out of the five chartered incubator items (https://github.com/tc39/incubator-agendas/issues/25), I do not plan to advance any of them next meeting, haha. Thereā€™s just too much contention around them right now. But maybe decorator metadata might be readyā€¦
20:08
<littledan>
of course once should be a template tag, once`${f}`(x) to take advantage of location-based caching ;)
20:09
<jschoi>
those new proposals sound interesting! they seem like tricky things to make built-in since caches/memoization sometimes have domain-specific retention policies; are you proposing hooks for those?
Oh yeah, thatā€™s the third proposal: maps and sets with cache-replacement policies, for the sake of memoizing but also other stuff. Iā€™m undecided whether to bundle memoization with CRP maps/sets into one proposal or not; I think weā€™re going to probably separate them.
20:09
<littledan>
I'm glad to see that you've gotten more involved over the past year!
20:09
<jschoi>
https://github.com/js-choi/proposal-function-memo https://github.com/js-choi/proposal-policy-map-set
20:09
<jschoi>
Yeah, thanks!
20:10
<shu>
jschoi: apologies, doesn't look like i'll have enough cycles this cycle to do an incubator call :(
20:12
<jschoi>
Yeah, itā€™s no problem; I think weā€™re all very thankful of you managing the incubators. Hopefully weā€™ll knock some stuff out during plenary.
20:13
<shu>
yes, might be a good one to do it with such a light schedule
21:07
<rbuckton (PTO: 7/5 - 7/16)>
iterable isnā€™t a thing, itā€™s a trait.
That's the case in every language/library that is prior art for iterator helpers. Python has itertools. C# has Enumerable+extension methods. F# has pipelines (and so will we). All operate on the "Iterable" not the "iterator".
21:17
<bakkot>
Java's streams are pretty similar to iterators and are where all of Java's equivalents of these methods are.
21:20
<bakkot>
also Rust's methods are all on the Iterator trait
21:20
<bakkot>
Boost (the C++ library) has filter_iterator and so on which are, obviously, on iterators
21:23
<bakkot>
Scala's AbstractIterator has filter and so on
21:23
<bakkot>
I dunno I feel like this is a lot of languages
21:34
<Ashley Claymore>
If range returned an iterator could the return value still include additional properties (start, end, step), similar to if it returned a ā€œrange instanceā€? Or should it only have next?
22:10
<ljharb>
prior art is informative, not constraining, and never automatically the right choice for JS.
23:29
<ljharb>
absolutely it could; whether it should is a different question