TC39 Delegates on 2022-07-21

00:02	<bakkot>	a downside of using a set-specific iterator method is that `union` only needs iteration, and so it would maybe be nice if `set.union(array)` worked. but it also seems bad for `set.union` and `set.intersection` to iterate with different methods
00:02	<bakkot>	I guess I would not terribly mind giving up on `set.union(array)` working, though
00:18	<rbuckton>	There are other approaches to computing a set intersection that don't depend on calling `has` on `arg`, at the expense of space.
01:51	<Kris Kowal>	ljharb "petty" wasn’t the right word today, sorry.
01:55	<Kris Kowal>	I’m still not sure what the right word is. It seemed like you’re saying don’t worry about the limitation to web browsers, it’s analogous to a sign that reads "no stealing (except thieves)". That just doesn’t seem to me like a good defense for the sign. But, again, at Agoric we’re satisfied that we can point to the meeting notes if it comes up again.
01:56	<Kris Kowal>	One thing is certain, though: I picked the wrong word!
02:40	<ljharb>	tbh that’s a fine analogy if we can ignore the inherent negative connotation. someone is welcome to steal if they’re content with the associated label and all it implies.
02:40	<ljharb>	anyones welcome to violate any spec they want as well, as long as they’re willing to give up on the label of complying with it ¯\_(ツ)_/¯
03:50	<snek>	does anyone know if the meetup today was recorded?
05:23	<Ashley Claymore>	The gmeet had a “recording” status on it, so possibly yes
12:40	<Chris de Almeida>	The gmeet had a “recording” status on it, so possibly yes the plenary was recorded?
13:13	<Ashley Claymore>	Sorry for the confusion. We were talking about the post plenary meet-up.
16:00	<rkirsling>	Keep seeing "deiter updates" and thinking, who's Deiter?
16:04	<Jack Works>	De-iterator
16:04	<Jack Works>	From HE Shi-Jun (hax)
16:06	<Michael Ficarra>	Ashley Claymore: rbuckton: the best explainer for protocols right now is the presentation at https://docs.google.com/presentation/d/1HnxJl4Iodf3I23e-ZDkw4F1LEkMRGUBFq6xxR0a9a_k/edit#slide=id.g3e3a1a53c0_0_0
16:06	<Michael Ficarra>	I'll work on providing better detailed documentation soon as I prepare for stage 2
16:06	<sarahghp>	dieter: https://www.youtube.com/watch?v=rZMoGyr1BFU
16:37	<HE Shi-Jun>	Keep seeing "deiter updates" and thinking, who's Deiter? Because double-ended queue is shorted to "deque", I use "deiter" as the abbr for double-ended iterator 😅
17:07	<shu>	what is `.indexed()`?
17:07	<shu>	oh i see
17:10	<Ashley Claymore>	for those reading Matrix later: https://github.com/tc39/proposal-iterator-helpers#indexed
17:12	<snek>	i wish we could just call it enumerate like every other language :(
17:13	<snek>	indexed is better than asIndexedPairs though
17:13	<snek>	so i'm not complaining too much
17:13	<shu>	otoh i would not have needed to ask the question if it was named `asIndexedPairs`!
17:14	<Kris Kowal>	Call and raise `toIndexEntries`
17:15	<littledan>	I have no strong opinion but I'd be fine with including `Iterator.prototype.flat`
17:15	<Kris Kowal>	(Never mind my bikesheddery joy. I’m fine with `indexed`.)
17:15	<littledan>	since it does make sense, as explained
17:16	<yulia>	No opinions from me either
17:18	<littledan>	oh I thought that flat/flatMap for iterator helpers was about iterators that yield arrays and such
17:18	<littledan>	I can definitely see how flat is difficult if we want it to be for iterators of iterators
17:18	<ljharb>	iterators that yield iterables, which includes arrays
17:18	<littledan>	right
17:19	<shu>	this explanation makes me want to omit flat, yes
17:20	<rbuckton>	Interesting. C#'s linq/Enumerable provides an index, which is quite useful
17:23	<Kris Kowal>	I found the argument compelling that you should use `indexed` and not rely on the `index` arg of `map` callbacks &c.
17:33	<bakkot>	I guess I am not super opposed to passing `index`. I am worried people will get confused but also some people will definitely get utility from it, so /shrug
17:33	<snek>	i am opposed to it
17:34	<shu>	for same reasons as mficarra?
17:34	<snek>	the original reasoning is that we explicitly force you to consider when you are introducing the counter which starts from 0
17:34	<shu>	i don't really see the harm
17:34	<shu>	why is that a good thing to force?
17:34	<rbuckton>	My concern about dropping `index` is theefold: Migrating code that uses `Array.prototype.map` to `Iterator.prototype.map` requires reaching for something new and refactoring your code to accept an array pair. Reusing existing named functions as callbacks requires them to either be polymorphic or the need to wrap the callback in an arrow to set the correct parameters. Reaching for an index requires allocating an array pair for every element, as opposed to a single number passed as an extra argument.
17:35	<shu>	i think the "element, index, collection" callback parameter order is pretty ingrained
17:35	<shu>	collection obviously doesn't make sense
17:35	<shu>	but i don't see the harm in providing index
17:35	<ljharb>	`for-of` doesn't provide an index
17:35	<rbuckton>	I almost never see anyone using `collection`, but frequently see folks using `index`.
17:35	<ljharb>	why would iterator helpers do so?
17:35	<shu>	for-of doesn't take a callback that's called per iteration
17:36	<shu>	what does that have to do with this?
17:36	<ljharb>	like the iterator protocol overall doesn't have a concept of indexes
17:36	<ljharb>	it just has next → value/done (ignoring return/throw)
17:36	<shu>	the users of this API won't be thinking of this in terms of the iterator protocol
17:36	<Kris Kowal>	yet 😉
17:36	<rbuckton>	`for..of` is fairly limited in any respect.
17:36	<shu>	they will be thinking of this in terms of "oh a per-iteration callback"
17:36	<snek>	the classic example was what if you add a drop at the start of your iterator chain
17:36	<littledan>	arguably it's weird that you can do .drop and now the indices are different from what they would've been. OTOH I agree with Shu's intuition point.
17:37	<shu>	it's semantically weird in a narrow semanticists' way imo
17:37	<littledan>	.toAsync() SGTM
17:37	<rbuckton>	I still find I'm more likely to use an npm package over iterator helpers, and not including `index` makes this even more likely for me.
17:37	<littledan>	I mean, this proposal is sort of betting against pipeline in general
17:38	<ljharb>	even with pipeline we'd still want lazy iterator helpers tho, no?
17:39	<littledan>	yes, but we might do a function-based version if we had pipeline
17:39	<snek>	we definitely cannot go back to arguing about whether these functions should be static
17:39	<ljharb>	in the current example i'd only use a pipeline on the `arr.values().map(foo) \|> AsyncIterator.from(%)` part
17:39	<rbuckton>	It's not that bad... `arr.values().map(foo) \|> AsyncIterator.from(%) \|> %.filter(async x => await bar(x))`
17:39	<snek>	topics ftw
17:40	<rbuckton>	That said, I have `toAsync` in my own iteration library, so I'm not opposed.
17:40	<littledan>	yeah I'm in favor of toAsync since we want to reinforce method chaining
17:40	<littledan>	and this does have to do with pipeline not existing but that's fine; it still doesn't feel like a wart.
17:42	<rbuckton>	If I'm working with an Iterator I almost always expect it to be lazy (unless I'm generating a scalar value with a reduce or toArray, etc.)
17:43	<littledan>	I was slightly surprised that drop was lazy but the explanation seems fine
17:43	<rkirsling>	eager `take` would be effectively "take and throw on the ground"
17:44	<littledan>	right
17:44	<Rob Palmer>	are we 100% we can't fix the override mistake?
17:45	<Kris Kowal>	We are not 100% sure we can’t fix the override mistake.
17:45	<Kris Kowal>	We are also not 100% sure we can.
17:45	<littledan>	I think it'd take some kind of opt-in due to the compat issues we discovered
17:46	<Rob Palmer>	"use flawless";
17:49	<shu>	+1 to not imposing requirement on all new intrinsics being programmatically reachable
17:49	<jschoi>	With regards to the Clojure indexed functions I referred to a few minutes ago, here they are:
17:49	<jschoi>	https://clojuredocs.org/clojure.core/map-indexed
17:49	<jschoi>	https://clojuredocs.org/clojure.core/keep-indexed
17:49	<jschoi>	I believe the reason for this split (rather than a single `indexed` function) was Rich Hickey wanting to avoid unnecessary indexed-entry garbage creation.
17:50	<snek>	out of curiosity does clojure have car and cdr
17:50	<rbuckton>	Confused by the argument order of `.zipWith`, would expect other iter to come first.
17:50	<rbuckton>	The argument order specified is terrible for static typing/contextual typing.
17:50	<jschoi>	It calls them `first` and `rest` and they work on lazy iterators.
17:50	<jschoi>	In fact they are the iteration primitives.
17:51	<apaprocki>	OT: Is there something I'm not seeing in Annex B that makes Number.toString(-0.0) return "-0" in browsers?
17:51	<Kris Kowal>	Very much will object to new intrinsics unreachable by transitive property walk from globalThis.
17:52	<rbuckton>	Is `.zipWith` part of the proposal or outside the scope?
17:52	<rbuckton>	Looks like its outside the scope currently.
17:52	<snek>	OT: Is there something I'm not seeing in Annex B that makes Number.toString(-0.0) return "-0" in browsers? which browsers? have not seen this and sounds incorrect
17:53	<snek>	Is `.zipWith` part of the proposal or outside the scope? all the methods he just listed are outside the proposal
17:53	<littledan>	I really like this proposal in its current form, overall. I want to note that Axel Rauschmayer is joining TC39 as an invited expert, and he may have input here as well.
17:54	<Kris Kowal>	Very much would relax position if another mechanism makes all intrinsics reachable programmatically.
17:54	<Kris Kowal>	I really like this proposal in its current form, overall. I want to note that Axel Rauschmayer is joining TC39 as an invited expert, and he may have input here as well. Axel!
17:54	<littledan>	yes I'm very happy about that
17:55	<apaprocki>	which browsers? have not seen this and sounds incorrect all browsers? chromium, safari, node just from looking
17:55	<ljharb>	OT: Is there something I'm not seeing in Annex B that makes Number.toString(-0.0) return "-0" in browsers? `-0.0` just parses to `-0`, and `Number.toString === Function.prototype.toString`, but `(-0).toString()` returns "0" for me
17:56	<apaprocki>	I guess I'm not describing it right -- they all do it in their REPLs
17:56	<apaprocki>	seemingly "undoing" what is spec'd
17:56	<ljharb>	right, that's where i'm trying it
17:56	<snek>	cannot repro
17:56	<ljharb>	are you by any chance on a website that might be patching stuff?
17:56	<snek>	what does `Number.prototype.toString.toString()` log out
17:56	<yulia>	Hey folks I need to leave early if you have any questions please ask Dan minor
17:57	<ljharb>	* native code for function tostring
17:57	<ljharb>	* native code from function tostring
17:57	<snek>	i mean for apaprocki specifically
17:58	<apaprocki>	No, the output of Number(-0.0) -0
17:58	<Rob Palmer>	today littledan is going to do a debrief on the steganography note-taking trial we conducted yesterday morning. please have a read of those notes so you can form opinions on their quality.
17:58	<apaprocki>	not Number.prototype.toString(-0.0)
17:58	<Kris Kowal>	+1 to not imposing requirement on all new intrinsics being programmatically reachable I’m curious what the downside is, apart from cognitive burden upon delegates.
17:59	<snek>	No, the output of Number(-0.0) -0 that's normal, but that's not tostring, that's the repl being helpful and telling you its -0
17:59	<snek>	https://gc.gy/126131365.png
17:59	<shu>	Kris Kowal: main reasoning from me is extra onus on design that has bearing on a niche use case
17:59	<apaprocki>	yeah, so just curious whether that is just informal convention or if that's written down anywhere
18:00	<ljharb>	apaprocki: informal convention; debug output for values in a repl has no spec i'm aware of (unless HTML has one for browsers)
18:00	<shu>	where an intrinsic can be made reachable without extra contortion, go ahead
18:00	<shu>	otherwise nothing compelling to me to require the contortion
18:01	<Kris Kowal>	i'm sure you're aware this is almost existential to the niche use case
18:01	<apaprocki>	https://gc.gy/126131365.png Yeah the interesting part to me is that every REPL/console implementation just seems to special-case this in its own way. Ours was missing this extra check and outputting 0, and special-casing -0 seemed crazy. Guess it's just the way it is...
18:02	<shu>	Kris Kowal: i am
18:02	<littledan>	I really like this proposal in its current form, overall. I want to note that Axel Rauschmayer is joining TC39 as an invited expert, and he may have input here as well. Note here that Axel has advocated for functions on iterables rather than methods on iterators; I'd suggest the proposal champions get in touch with him to discuss further.
18:02	<shu>	Kris Kowal: and there is a good solution here as markm has pointed out: put efforts there?
18:03	<snek>	Yeah the interesting part to me is that every REPL/console implementation just seems to special-case this in its own way. Ours was missing this extra check and outputting 0, and special-casing -0 seemed crazy. Guess it's just the way it is... we (nodejs) found a cool bug in v8 because of this https://github.com/v8/v8/commit/56f6a76
18:03	<shu>	with getIntrinsics
18:03	<littledan>	I'm really confused about the motivation for double-ended iterators. If it's destructuring, I think we can support `let [x, ...y, z] = a` without this, just through iterating through the rest until it ends
18:03	<rbuckton>	Note here that Axel has advocated for functions on iterables rather than methods on iterators; I'd suggest the proposal champions get in touch with him to discuss further. I very much share this perspective.
18:03	<shu>	(getIntrinsics remains having implementation concerns to be clear, so it's not also like it's smooth sailing)
18:03	<ljharb>	i would love to hear more about these
18:03	<rbuckton>	I'm really confused about the motivation for double-ended iterators. If it's destructuring, I think we can support `let [x, ...y, z] = a` without this, just through iterating through the rest until it ends The last slide was specifically about the performance implications of that approach.
18:04	<apaprocki>	we (nodejs) found a cool bug in v8 because of this https://github.com/v8/v8/commit/56f6a76 ah subnormals... IEEE754 my old friend
18:04	<Kris Kowal>	with getIntrinsics If getIntrinsics reveals all new intrinsics, then mitigating supply chain attacks remains feasible.
18:04	<shu>	how can getIntrinsics not reveal all intrinsics?
18:04	<shu>	isn't that what it does?
18:04	<Kris Kowal>	that is its purpose, yes.
18:05	<ljharb>	that's not its purpose, but with the enumeration requirement yes, that's what it will also do.
18:05	<ljharb>	its primary purpose is to get a single specific known intrinsic. its secondary purpose is now to enumerate/iterate all intrinsics.
18:05	<shu>	ljharb: mainly need to audit the intrinsics that are currently not kept on the NativeContext in V8, how many of those we have, how much more memory use does keeping those incur for low-memory environments (Android)
18:06	<ljharb>	thanks - is that something that can be investigated early enough in the stage process to avoid surprises later?
18:06	<shu>	and, if unacceptable, figure out mitigation, then figure out acceptability of those mitigation techniques
18:06	<snek>	ljharb: mainly need to audit the intrinsics that are currently not kept on the NativeContext in V8, how many of those we have, how much more memory use does keeping those incur for low-memory environments (Android) i have bad news about nativecontext lol, so much random stuff on there
18:06	<shu>	sure i know
18:07	<shu>	ljharb: a soft deadline would help me prioritize, depends on what timeline you want?
18:07	<littledan>	The last slide was specifically about the performance implications of that approach. So, yes, I get that you end up having to allocate the array a little bigger and then trim it back, but I am not convinced that this will be anything like a performance bottleneck. JS Array implementations already need to be able to handle that usage pattern somewhat efficiently. It's a lot less costly operation than the rest of the iteration protocol.
18:07	<Kris Kowal>	For the hardened JavaScript use case, the qualifiers can be more specific to any intrinsics programmatically reachable from "the shared intrinsics", which we would like to cover as much as possible, but can’t for example cover Intl for other reasons.
18:07	<littledan>	probably I'm missing something
18:07	<ljharb>	ljharb: a soft deadline would help me prioritize, depends on what timeline you want? i'm hoping to ask for stage 2 in september or november; assuming that happens, then it'd be great to have the investigation done by the end of the year so the path to stage 3 is clear
18:08	<shu>	ok
18:08	<shu>	i didn't say yes!
18:08	<shu>	i said ok, as in ack
18:08	<ljharb>	lol fair enough, i still appreciate the explanation and consideration
18:08	<snek>	is every other line of this slide a different font size
18:08	<rkirsling>	I was going to ask
18:08	<rkirsling>	is it like, a font-size-based justification algorithm?
18:08	<rkirsling>	it's trippy
18:09	<littledan>	is every other line of this slide a different font size Hax does this for conference talks too--it's actually a pretty nice way to maintain visual engagement in those cases
18:09	<littledan>	looks especially nice with a slide with a few ideographic characters totally filling the screen
18:10	<rkirsling>	but it was a paragraph of text
18:12	<rkirsling>	like, it's a really unpleasant fun-house mirror effect
18:21	<snek>	in most languages they meet in the middle right?
18:21	<Michael Ficarra>	I just got how you would implement Iterator.prototype.take to be eager and omg no it is not eager
18:21	<snek>	lmao
18:21	<Michael Ficarra>	lol that's such a bad idea I couldn't even fathom it
18:22	<snek>	takeWithCache
18:22	<Michael Ficarra>	might as well `toArray`/`slice` at that point
18:23	<snek>	technically all of the iterator helpers could be implemented in this way
18:23	<Michael Ficarra>	completely defeating the point of iterators, sure
18:25	<littledan>	Can we have a 5-minute extension to go through the queue
18:25	<shu>	i think it's important for us to get to dan's queue item
18:25	<shu>	direct feedback on this question hax wants feedback on
18:27	<bakkot>	ok but implementations would definitely otpimize this for built-ins
18:27	<bakkot>	and it would be kind of annoying that once you have a userland wrapper of the built-in it suddenly gets many orders of magnitude slower
18:28	<bakkot>	also I do kind of want to get the last thing from sets sometimes
18:29	<snek>	i often want the nth things from sets
18:33	<shu>	why do you think sets are randomly accessible
18:33	<shu>	unfortunately they actually are
18:33	<shu>	but i don't want to codify that in practice
18:34	<snek>	are there any practical ordered collection implementations that are not randomly accessible
18:35	<snek>	(i ask this seriously, i don't know the answer)
18:35	<shu>	me neither
18:35	<Michael Ficarra>	snek: practical is a qualifier that can be used to exclude anything you don't like here
18:36	<Kris Kowal>	I went to great trouble to make a splay tree that was indexable. It was clever.
18:36	<snek>	well i mean, we do have certain requirements in the spec like amortized O(1) access and such
18:36	<littledan>	I mean, Maps and Sets are deterministically ordered based on some implementation (maybe in SM?) that had some sort of fancy encoded doubly linked list for ordering, IIRC
18:36	<snek>	sounds cool
18:36	<snek>	i should read more spidermonkey code
18:36	<littledan>	fancy with XORs of pointers and such
18:37	<snek>	lmao that's a classic
18:37	<littledan>	I don't know if it's still what they use
18:39	<snek>	LRU in the language would be awesome
18:39	<snek>	i see that used everywhere
18:40	<Kris Kowal>	If we wait, IBM’s patent on ARC will expire and we will only need one.
18:40	<bakkot>	https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tables
18:40	<bakkot>	is how set/map are ordered
18:40	<bakkot>	in implementations
18:41	<bakkot>	I believe
18:41	<bakkot>	it very small and nice, nothing excessively tricky
18:41	<snek>	thats not how v8's works afaict
18:41	<snek>	but that is neat
18:43	<bakkot>	got that link from syg but he might be out of date
18:43	<bakkot>	are there any practical ordered collection implementations that are not randomly accessible linked lists?
18:43	<bakkot>	"practical" may be doing some work to rule that out but it's the obvious one
18:43	<snek>	yeah that's what dan mentioned
18:44	<littledan>	Oh is this WeakRef case my fault for not removing that use case from the WeakRefs readme?
18:44	<littledan>	PRs welcome there
18:44	<littledan>	sorry
18:44	<snek>	i just meant like, there are many ways to write things, but what are implementations actually using
18:44	<littledan>	I assumed people would put a strongly held part at the beginning but it didn't show up in my example
18:44	<snek>	much like how we raised the requirements on sorting to be stable
18:46	<bakkot>	I really like this proposal in its current form, overall. I want to note that Axel Rauschmayer is joining TC39 as an invited expert, and he may have input here as well. I read his feedback and was very confused by it; he wants this to work with iterables, and to be static functions, but working with iterables is just a fundamentally different thing than working with iterators
18:46	<bakkot>	it would be an entirely different proposal
18:46	<bakkot>	a different, worse proposal
18:48	<bakkot>	maybe we should put a link to https://stackoverflow.com/a/28513908 in the iterator helper readme
18:48	<snek>	might be nice to discuss dan minor's item since that's actually a potential stage 1 blocker
18:49	<Michael Ficarra>	this is stage 0, there is no "current proposal"
18:49	<littledan>	it would be an entirely different proposal Well, yeah, I don't think he disagrees
18:49	<bakkot>	then I don't understand the feedback
18:49	<bakkot>	they don't particularly conflict
19:03	<shu>	jschoi: i would like to help champion this if eviction triggers are in scope, and if not, i'll champion its sister proposal
19:06	<jschoi>	Thank you. Let’s keep it in one proposal for now; welcome on board. (I think Hemanth H.M, the other co-champion, should be okay with it too!)
19:13	<rbuckton>	Are we only considering a very basic cache approach, or is the possibility of more complex caching strategies (i.e., cache key dependencies, user-defined change monitors, absolute or sliding expiration, etc.) on the table?
19:13	<jschoi>	If we wait, IBM’s patent on ARC will expire and we will only need one. Yes, I really would like an ARCMap. If wishes were horses… Do Ecma or any of the big engines have a patent policy regarding patents that are about to expire in the US? (Also, I wonder if ARC’s patent is longer in other countries…)
19:30	<Chris de Almeida>	ARC patent was assigned to Intel so it's out of my hands ☹️
19:31	<Chris de Almeida>	expires in Feb 2024 if there are no further adjustments
19:31	<Chris de Almeida>	could write a letter to Intel asking nicely for RF license
19:32	<Chris de Almeida>	Intel is an ECMA member
19:40	<jschoi>	Are we only considering a very basic cache approach, or is the possibility of more complex caching strategies (i.e., cache key dependencies, user-defined change monitors, absolute or sliding expiration, etc.) on the table? Also, everything is on the table for discussion in https://github.com/tc39-transfer/proposal-policy-map-set/issues/2.
19:42	<jschoi>	Also, while writing https://github.com/tc39-transfer/proposal-policy-map-set/issues/7, I’m wondering if we shouldn’t try to revive that old Observables proposal, or at least keep the trigger API to be compatible with Observable…
19:48	<Chris de Almeida>	Consistent with its participation in standard-setting organizations, Intel may voluntarily commit to license its patents that are “essential” for compliance with a standard on fair, reasonable and non-discriminatory (“FRAND” or “RAND”) terms. 🤔🤔🤔
20:01	<littledan>	Intel is an ECMA member Yeah, we can feel free to go ahead with putting this in the spec, unless Intel withdraws in time, since we have our royalty free patent policy in TC39
20:01	<jschoi>	littledan: Can you leave a comment on #2?
20:02	<snek>	what is ARCMap
20:03	<Kris Kowal>	Adaptive Replacement Cache
20:03	<Kris Kowal>	It is an algorithm that slides between LRU and LFU depending on the observed effectiveness of each strategy on the working set over time.
20:04	<snek>	frecency?
20:05	<snek>	i guess this is technically not raw frecency
20:05	<snek>	interesting though
20:06	<Chris de Almeida>	Yeah, we can feel free to go ahead with putting this in the spec, unless Intel withdraws in time, since we have our royalty free patent policy in TC39 In case the implementation or use of the resulting standard incorporating said contributions requires patents or any other kind of intellectual property rights that I (or my represented organization) own, I (or my represented organization) grant a license free of charge to an unrestricted number of applicants on a worldwide, non-discriminatory basis, and under other reasonable terms and conditions to manufacture, use and/or sell implementations of the standard. https://www.ecma-international.org/tc39-royalty-free-technical-committee-members/ according to that page, Intel signed that agreement. IANAL but that's compelling
20:06	<littledan>	indeed
20:08	<snek>	ibm and intel have both signed it
20:08	<snek>	very compelling
20:08	<Chris de Almeida>	right. as the patent has been assigned to Intel though, it's 100% theirs at this point
20:09	<Chris de Almeida>	there is a variant licensed under CDDL as well: https://github.com/openzfs/zfs/blob/master/module/zfs/arc.c
20:13	<ljharb>	it'd still likely be up to intel's legal team whether they contributed it in the first place tho
20:14	<littledan>	well, I don't think we need to worry about that; I think the standards IPR opt-out process is our safeguard to reference
20:14	<ljharb>	i would suspect the employees of that company may want to worry about it tho
20:14	<littledan>	oh, yeah, that contribution seems complicated, not contradicting you there
20:14	<ljharb>	i wouldn't want someone to lose their job by trying to sneak a patented thing into the spec :-)
20:15	<littledan>	I don't think we'd put that at risk; we'd be just using the standards IPR opt-out process
20:15	<littledan>	IMO the main thing is, are we OK with proceeding with the things that happen after Stage 3 while risking that they may later opt out and not license the patent?
20:16	<ljharb>	right, i'm saying that i'm pretty sure all of my employers would have fired me for knowingly contributing a patented thing and requiring the legal team to intervene later
20:16	<ljharb>	the patent optout is an escape hatch, it's not carte blanche for delegates to volunteer their employer's patented IP
20:16	<snek>	would your employer's legal team need to intervene though?
20:16	<littledan>	well, someone would need to find out and decide to opt out
20:16	<rkirsling>	python has @memoize, no?
20:17	<littledan>	so, yeah, check with your employer before contributing their IPR!
20:17	<Chris de Almeida>	so I don't know about Intel, but at IBM -- and I'm trying to be careful with my words here 🙂 -- being able to license or release stuff open source is predicated on whether or not it will compete with IBM products/services and affect the business in some way. (lost profit, etc.). I think for what we would want to be doing with ARC, it's difficult for me to see how it would compete with Intel's business interests, so strikes me as uncontroversial for the IP team to grant a license outright
20:17	<rkirsling>	like I would assume we would want this to be a decorator
20:17	<bakkot>	rkirsling: that's not what it's called, but yes: https://docs.python.org/3/library/functools.html#functools.cache
20:17	<rkirsling>	oops, thanks
20:17	<snek>	this would be an awesome decorator if we supported decorators on functions lol
20:17	<snek>	i will never not be salty about this
20:18	<rkirsling>	oh oops right
20:18	<littledan>	Function decorators are held up because they don't really jive with function hoisting. IMO we should just say that decorated functions are not hoisted, but not everyone agrees.
20:18	<littledan>	Python functions aren't hoisted, that's how they get through this
20:18	<bakkot>	function decorators are also held up because you can just call a function instead
20:18	<bakkot>	which doesn't work for class properties
20:18	<littledan>	that is true in Python as well
20:18	<ljharb>	wait, so i could use a function declaration but cleanse it of hoisting with `@(x => x)` or something? that seems nice
20:19	<bakkot>	so there's a lot more motivation for class properties
20:19	<littledan>	but yes that's true
20:19	<snek>	imagine if we had capture operator`@(& &1)`
20:23	<littledan>	it's hard for me to picture why things would be limited to the first argument... you can have nested maps
20:23	<Kris Kowal>	Also user-code maps with complex key relations.
20:23	<littledan>	This does seem polyfillable, and it should be, but it still seems like a common need that makes sense to promote to the stdlib
20:36	<bakkot>	that is true in Python as well only sort of; python doesn't have function expressions
20:38	<Michael Ficarra>	it seems like this proposal could go straight to stage 2, there is really only 1 way to design a solution to this problem, right?
20:39	<bakkot>	well, you could use syntax
20:39	<Michael Ficarra>	Kris Kowal: can you explain why you prefer syntax? that was kinda unclear
20:40	<rkirsling>	yeah why would this not just be pulling lodash functions into the stdlib
20:40	<bakkot>	you can type this fine in TS
20:40	<Kris Kowal>	Michael Ficarra: shu’s position is consistent with ours.
20:40	<bakkot>	as long as the keys are passed inline, anyway
20:41	<shu>	IF they're inlined
20:41	<shu>	computed property accesses are also fine if they're just string literals
20:41	<littledan>	what would be harder is for JS engines to make ICs based on the keys being passed inline, the way they can for destructuring
20:41	<shu>	that doesn't mean you should favor computed property accesses
20:41	<shu>	yes, all the special reductions for pick/omit seems not desirable
20:41	<littledan>	this sort of limitation is common in TS, OTOH
20:41	<shu>	like if it's not too onerous to extend syntax
20:41	<shu>	maybe that's fine
20:42	<shu>	but i wanna see something concrete
20:42	<Michael Ficarra>	for remote meetings, we need a little more time to object than that, I can't even unmute in that time (though I do not wish to object here)
20:44	<littledan>	the syntax seems neat as well as optimizable and typeable, but... I dunno, it will take me more time to be convinced that we should add it.
20:44	<littledan>	maybe we should
20:44	<rkirsling>	strong 😬 toward the syntax personally
20:45	<Michael Ficarra>	I think I'd rather not have this than have syntax for it
20:45	<Michael Ficarra>	and I do want it
20:46	<snek>	stage 1 is a good place for this
20:46	<shu>	Michael Ficarra: how come?
20:47	<shu>	i am not pro-syntax to be clear, i'm pro exploration of syntax solutions until we make the call
20:47	<Michael Ficarra>	shu: I don't think it's worth incurring syntax cost, even though it is useful and common
20:47	<shu>	is that more than a feeling
20:47	<snek>	i was gonna say i don't think its common enough to warrant its own syntax
20:47	<shu>	okay, so it's about popularity
20:48	<Michael Ficarra>	it's about cost-benefit
20:48	<Michael Ficarra>	syntax has cost and we have to use it on things that have outsized benefits
20:48	<Michael Ficarra>	APIs are basically free
20:48	<snek>	i guess i also feel like we're not losing anything if this is a builtin function, like the api isn't worse
20:48	<littledan>	Right, if this were extremely common and we really wanted to make it really terse and allow engines to have ICs here, the syntax might make sense
20:49	<shu>	my point is that it's not free
20:49	<shu>	APIs for property accesses that are expected to be very common end up not being free for performance
20:49	<shu>	so we should have that in the cost-benefit
20:49	<littledan>	I'm not convinced it's so bad to have the string keys. Not as optimizable, but typeable in practice, and I'm not sure if it makes people's programming patterns more dynamic than they are today
20:49	<shu>	instead of just "syntax are expensive from a language design POV"
20:49	<shu>	that might be true
20:49	<Michael Ficarra>	shu: if we don't add it to the std lib though, people are gonna keep writing their own anyway
20:49	<littledan>	arguably when we did Object.entries we already crossed the bridge of being OK with objects as key/value things (which they always were anyway)
20:50	<shu>	I'm not convinced it's so bad to have the string keys. Not as optimizable, but typeable in practice, and I'm not sure if it makes people's programming patterns more dynamic than they are today i could be convinced of this
20:50	<Kris Kowal>	I have definitely asked myself why I can’t just `phenomenalCosmicPowers.{itty, bitty, living, space}`.
20:50	<shu>	i think people use Object.entries in a dynamic way, while pick/omit seem to assume static knowledge of the shape of the object you're working with
20:50	<bakkot>	also while I think this will be common it will not be that common
20:50	<snek>	i don't think the performance is so critical that we must take the most statically analyzable option
20:50	<ljharb>	one of the motivations is that there are use cases with N properties, so you can't just type it all out statically - so you'll always be forced to pass strings
20:51	<snek>	we certainly could, but i am not yet convinced anyway
20:51	<shu>	yes, i could be convinced either way
20:51	<littledan>	also while I think this will be common it will not be that common Just be clear: is this common or not common!?!?!?!
20:51	<shu>	i am just pushing back against "APIs are free"
20:51	<littledan>	either the whole program is Object.pick() or it's not called
20:51	<shu>	the thing that has cost here isn't just the weight of the language!
20:51	<ljharb>	if an API is so common that people are preferring it over syntax, can't we add syntax at that point?
20:52	<shu>	i don't see why we need to do that exploration via stdlib
20:52	<shu>	instead of just the userland libraries?
20:52	<ljharb>	historically we've preferred to add syntax after trying something out as API, like object spread/rest after Object.assign
20:52	<ljharb>	userland's demonstrated that we need these functions for a long long time
20:52	<ljharb>	the objection seemed to be about the potentially increased usage if it's standardized, right?
20:52	<ljharb>	so if that happens, then isn't that a stronger argument for syntax?
20:53	<littledan>	I think that, given that the committee is moving a lot more stuff these days, we can just evaluate the syntax option and make a call, rather than potentially doing one and then the other (with potential not-fun mismatch!)
20:53	<rkirsling>	tbh `abc.{a,b}` looks like it'd be an alternative syntax to `let {a,b} = abc;`, not creation of a new obj
20:53	<littledan>	yeah it's a nice design of the syntax!
20:53	<littledan>	oh oops that's the opposite of what you're saying?
20:54	<snek>	i also do not like the exact syntax that was proposed
20:54	<rkirsling>	yeah I mean that `.{}` doesn't seem weird as a syntactic construct but it looks like it'd be creating bindings in the current scope
20:54	<Kris Kowal>	`abc.{a,b}` is obvious to me, to wit, I’ve reached for that exactly in my work and been sad.
20:55	<ptomato>	`{ abc.{a,b} }` would be clearer to me, and have synergy with unix shell text expansions
20:57	<snek>	i still feel like the clearest thing to me is a nice api where you're saying something like `Object.pick(o, [k1, k2, k3])`
20:57	<snek>	i feel like that is superior to the syntax in terms of everything except potential engine optimization
20:58	<Kris Kowal>	I will grant that other irresponsible generalizations of this syntax seem reasonable to me up to and including `ab.(a + b) === ab.a + ab.b`
20:58	<shu>	here's an unpresented proposal about syntax in the same space: https://github.com/rtm/js-pick-notation
20:58	<shu>	no endorsement! something to chew on though
21:03	<shu>	do people actually write dynamic sequence of callbacks?
21:03	<shu>	that seems pretty hard to reason about
21:04	<shu>	that said i also love first-class goto labels
21:06	<littledan>	+1 to ljharb 's point
21:10	<rbuckton>	do people actually write dynamic sequence of callbacks? RxJS rings a bell (along with the myriad libraries that depend on it)
21:24	<rbuckton>	I really would like an operator, but I would also like to not continually alienate large sections of the ecosystem that really would like unary function pipelining
21:25	<littledan>	well, JS really tried to thread this needle with his middle proposal with both a topic and unary pipelining, but everyone thought that was too complex
21:28	<bakkot>	what if instead, only API and not syntax
21:28	<rkirsling>	I don't think this can be considered a different problem space; it's only a different solution space
21:28	<sarahghp>	I think actually having one version implemented will get people to calm down about their version
21:28	<sarahghp>	as long as it's still theoretical, you can argue
21:29	<jschoi>	well, JS really tried to thread this needle with his middle proposal with both a topic and unary pipelining, but everyone thought that was too complex Smart mix… 🥲
21:29	<rbuckton>	If we have API and no syntax, why not not have F# pipes? Hack-style's benefit is in working with `yield`, `await`, and arbitrary expression evaluation. If we were to throw those concerns out in favor of an API, how is that any different from having chosen F#-style?
21:29	<bakkot>	because syntax is much more expensive than APIs, as previously mentioned
21:33	<rbuckton>	Except `\|>` without a topic or PFA has no conflict with any existing syntax (i.e., no NLT, no changes to InputElementX goals, etc.), and is much more readable than `Function.pipe(x, F(...), ...)`.
21:33	<bakkot>	i do kind of wonder what the rates are would be to get people to fix up the bot
21:33	<bakkot>	like can I just hire two or three friends who are between jobs at $30/hr to do the bot shepherding
21:35	<rkirsling>	it was appropriate to call out insensitivity
21:35	<rkirsling>	that wasn't a CoC issue
21:35	<Michael Ficarra>	we have 11 topics on TCQ and no time left on this topic...
21:36	<jschoi>	Except `\|>` without a topic or PFA has no conflict with any existing syntax (i.e., no NLT, no changes to InputElementX goals, etc.), and is much more readable than `Function.pipe(x, F(...), ...)`. I still remain concerned that the meaning of `x \|> veryLongThing(veryLongThing, ^^, veryLongThing)` completely changes semantics (from an n-ary function call to a unary tacit call on a metafunction call) when omitting the `^^`. This is a big burden on readers.
21:36	<jschoi>	This is also why I pushed in those early errors requiring and guaranteeing that the topic is in every pipe body.
21:36	<rbuckton>	I did not support "smart-mix" for that very reason.
21:37	<HE Shi-Jun>	I also did not support smart mix, smart, but not smart enough :P
21:37	<jschoi>	I did not support "smart-mix" for that very reason. Yes, I sympathize. Though at the very least smart mix limited unary-tacit-calls-on-metafunction-calls to relatively simple and quickly readable property chains.
21:37	<rbuckton>	Hack-style requires a topic. F#-style requires unary function application. PFA would have helped with producing unary functions for use with F#.
21:38	<HE Shi-Jun>	I support F# + PFA :P
21:40	<HE Shi-Jun>	I also feel it's not right to call hack-style to hack-style, because Hack actually not support await... I also feel it's not right to call it topic-style because it's not like topic usage in real topic style languages like perl... In real topic style languages, topic mostly are implicit, only rare cases u need explicitly use topic ref.
21:41	<jschoi>	I think “topic style” is appropriate. The word “topic” (as Perl uses it) comes from linguistics: https://en.wikipedia.org/wiki/Topic_and_comment
21:41	<jschoi>	The topic is explicit in many human languages.
21:43	<HE Shi-Jun>	I don't agree. Topic means it's the context so people know the context of it and do not need to repeat explictly call it, this is what I understand of topic style.
21:43	<jschoi>	See also: https://www.perl.com/pub/2002/10/30/topic.html/
21:44	<jschoi>	I don't agree. Topic means it's the context so people know the context of it and do not need to repeat explictly call it, this is what I understand of topic style. Like in Japanese, topics are explicit and marked with wa は: https://en.wikipedia.org/wiki/Topic_marker
21:44	<HE Shi-Jun>	In perl, many operations just use $_ but only in rare case u need explicitly use $_
21:44	<jschoi>	And in Korean, topics are marked with 은/는.
21:44	<jschoi>	Anyways, Perl took it from that original linguistics usage.
21:44	<rkirsling>	and in Chinese it just sits in front
21:44	<bakkot>	I suspect IS is about to suggest recordings and we are not going to get consensus for recordings
21:45	<jschoi>	Huh, apparently Classical Chinese did have a topic marker: 者 (zhě). Today I learned.
21:45	<bakkot>	I am even more leery of recordings these days than I was two years ago given stuff like https://github.com/neonbjb/tortoise-tts
21:45	<Michael Ficarra>	this is why I suggested we do this on the Reflector instead of in plenary...
21:46	<Michael Ficarra>	I KNEW this topic would drag on forever
21:47	<snek>	i don't think it even makes sense as like, a discussion topic
21:48	<Michael Ficarra>	chairs, I don't think we should extend this topic
21:48	<snek>	the conversation happening in the queue rn
21:48	<Michael Ficarra>	we had another topic from Richard following this and I don't think there's any reason to have this in plenary over the Reflector
21:49	<snek>	yeah agree
21:49	<bakkot>	we put conclusions in the notes; they are easy to find
21:49	<HE Shi-Jun>	Huh, apparently Classical Chinese did have a topic marker: 者 (zhě). Today I learned. Yeah in classical chinese 者 will only be used if we want to make emphasis. In most cases, it is omitted.
21:49	<bakkot>	I have never had difficulty finding those
21:50	<bakkot>	I don't think there would be that much benefit in putting those in their own docs
21:50	<Chris de Almeida>	I think it's helpful to discuss the topic, so long as people keep feedback succinct and keep it moving.
21:52	<bakkot>	what annoys me is that I am certain google could dramatically improve the STT if they really wanted to with like 5% of the budget they spent on PaLM
21:52	<bakkot>	but I can't make them do it and no one else seems to have a better realtime model, or at least this was true in 2020
21:53	<snek>	scrubbing through audio would suck lol
21:53	<HE Shi-Jun>	So IMO, topic reference is more like implicit parameter in other languages (eg. `it` in Kotlin), not like $_ in perl
21:53	<HE Shi-Jun>	But in those languages, implicit param is the feature of function/block, not bind to some operator like pipeline.
21:54	<apaprocki>	we would still have to pay someone to transcribe the audio/video
21:54	<bakkot>	yeah recordings alone are almost useless unless you also run STT on them
21:54	<snek>	i'm not against recordings but they are not useful in place of notes
21:54	<snek>	they serve a different function
21:54	<Chris de Almeida>	they will be ~99.6% useless
21:54	<jschoi>	So IMO, topic reference is more like implicit parameter in other languages (eg. `it` in Kotlin), not like $_ in perl In addition to the original use from linguistics (which can be explicit or implicit), “topic variables” also have been used on explicit-only variables: https://rosettacode.org/wiki/Topic_variable But I don’t want to derail the thread; this is all about steganography right now.
21:55	<shu>	stenography
21:55	<jschoi>	Oops.
21:56	<bakkot>	... what if the bot goes on strike, will IS get ecma to pay for stenography at that point
21:56	<jschoi>	I like my topic better. Let’s talk about TC39 steganography…
21:56	<bakkot>	the bot could go on strike
21:56	<Kris Kowal>	I like my topic better. Let’s talk about TC39 steganography… why not both
21:56	<shu>	i feel like the only relevant topics of discussion are
21:56	<shu>	who wants to pony up cash are volunteers willing to continue
21:57	<rkirsling>	the bot could go on strike I mean yeah, I was going to suggest just refusing to do notes for a whole meeting
21:57	<Kris Kowal>	seize the means of production
21:57	<rkirsling>	that'd hurt everyone but...
21:57	<apaprocki>	who wants to pony up cash are volunteers willing to continue This convo is definitely affecting 2.
21:57	<Kris Kowal>	I can say I won’t take notes because I’m not smart enough to listen and write at the same time. Also: RSI risk.
21:58	<Kris Kowal>	The times I’ve volunteered left me a dried out husk.
21:58	<ptomato>	if stenography gets torpedoed because of the opinions of people who do not volunteer regularly, then I am unlikely to be willing to continue volunteering to take notes
21:58	<Chris de Almeida>	if stenography gets torpedoed because of the opinions of people who do not volunteer regularly, then I am unlikely to be willing to continue volunteering to take notes same
21:59	<ljharb>	someone who notetakes regularly needs to say that on the queue please.
22:00	<ptomato>	we're unlikely to get to the end of the queue at this point
22:00	<snek>	"point of order: notetakers are considering strike" lol
22:00	<ljharb>	"discuss current topic" is often relevant :-p but fair
22:01	<HE Shi-Jun>	In addition to the original use from linguistics (which can be explicit or implicit), “topic variables” also have been used on explicit-only variables: https://rosettacode.org/wiki/Topic_variable But I don’t want to derail the thread; this is all about steganography right now. Thank u for the link, and the definition it use: "A topic variable is a special variable with a very short name which can also often be omitted." 😉
22:04	<bakkot>	if we paid all the delegates who are taking notes at our going rates, we would cost... like an order of magnitude more than the professional stenographers
22:05	<Chris de Almeida>	new rule: don't shoot down the steno if you have no alternate solutions with a concrete plan to manifest them
22:05	<Chris de Almeida>	🤷
22:05	<shu>	it is a crass thing, but it would be a good visceral reminder to tally up the per-hour cost (probably per minute given the attendance and our employers, actually...) of tc39
22:07	<snek>	ptomato ty for your queue item ❤️
22:07	<sarahghp>	I would like to suggest that we track how long any given person speaks in a meeting and then make the notetaker list in that order for the next meeting
22:07	<snek>	I would like to suggest that we track how long any given person speaks in a meeting and then make the notetaker list in that order for the next meeting rip istvan
22:08	<apaprocki>	we would lose spec download stats
22:09	<bakkot>	I would like to suggest that we track how long any given person speaks in a meeting and then make the notetaker list in that order for the next meeting lots of people aren't really physically/mentally able to take notes in realtime, tbf
22:09	<rkirsling>	people mentioned RSI but the visual burden is also intense
22:10	<sarahghp>	then we should pay pros
22:10	<bakkot>	yes we should
22:10	<snek>	indeed
22:11	<ljharb>	it would be nice to end early
22:12	<Michael Ficarra>	I thought today only went to 15:00 Pacific?
22:12	<ljharb>	nope, 16:00
22:13	<Michael Ficarra>	draft schedule lies...
22:13	<sarahghp>	yes all the way to 4 poor thing 😜
22:13	<ljharb>	or the agenda does, i guess
22:14	<Michael Ficarra>	yes all the way to 4 poor thing 😜 I'm not Pacific either
22:14	<jschoi>	I edited all three days’ notes of a plenary last year, and it took two entire weekend days, and I do not plan to do it again.
22:14	<jschoi>	(are we going to get to incubator chartering)
22:14	<sarahghp>	I'm not Pacific either I'm sorry I just meant my teasing to hit jordan, not other casualties!
22:18	<apaprocki>	JSConf.eu paid live stenographers and it was amazing
22:18	<apaprocki>	Everyone loved it
22:18	<snek>	yeah that was awesome
22:19	<Kris Kowal>	Roguelike, a very tiny niche boutique conference, also paid a stenographer.
22:20	<bakkot>	another point, which I am not going to make on the queue, is that IMO the errors that the transcriptionist makes are much easier to correct after the fact than the errors the bot makes
22:20	<bakkot>	like sometime the transcriptionist misses a word or gets something wrong, but it's rarely outright gibberish
22:20	<rkirsling>	I think Shane did cover that
22:20	<Michael Ficarra>	the worst stenographer errors were when they got behind and skipped a sentence or two, which is pretty hard to correct even moments later
22:21	<bakkot>	the bot does that sometimes and I fix it up ok when I'm doing notetaking
22:21	<bakkot>	(usually when the wifi drops or something)
22:21	<bakkot>	admittedly not as often, though
22:22	<Michael Ficarra>	I'm really hoping the stenographer will be significantly better with non-native speakers than the bot was; the bot was awful
22:25	<mpcsh>	Rob Palmer ☝️
22:25	<jschoi>	Roguelike, a very tiny niche boutique conference, also paid a stenographer. (You’re going to get me back into roguelikes again……For me, “true” Berlin Interpretation roguelikes might be the purest form of game in the world.)
22:26	<ryzokuken>	`#tc39-nethack`
22:27	<jschoi>	…Also, did any breakout sessions happen in this plenary? I cannot tell because I am remote. Actually, I don’t know how the breakout sessions even would work; would they have been put on the TCQ agenda, and would they have been broadcast remotely?
22:27	<mpcsh>	…Also, did any breakout sessions happen in this plenary? I cannot tell because I am remote. Actually, I don’t know how the breakout sessions even would work; would they have been put on the TCQ agenda, and would they have been broadcast remotely? having been to in-person plenary before covid: there's no such thing as a breakout session, only informal hallway conversations during break times
22:28	<jschoi>	Waitamoment…We haven’t done incubator rechartering, right? shu
22:29	<snek>	there was a breakout thing once but it was because there was an entire day of empty agenda
22:33	<Michael Ficarra>	mpcsh: we have definitely done true breakout sessions before
22:33	<Michael Ficarra>	one of the Apple campus meetings and the one in that weird NYC cult building are at least 2 I can recall
22:34	<jschoi>	one of the Apple campus meetings and the one in that weird NYC cult building are at least 2 I can recall ………NXIVM’s building?
22:34	<Michael Ficarra>	nah, different cult
22:36	<ljharb>	it was the masons, or something
22:36	<shu>	yeah
22:36	<shu>	they had like, a gilded statue of george washington on one of the floors
22:37	<Michael Ficarra>	lots of pictures of old white dudes in costumes hung on the walls
22:37	<snek>	is that not normal for all buildings?
22:37	<snek>	oh this is delegates
22:41	<bakkot>	oh yeah the masonic hall
22:42	<bakkot>	and like kanye was there or something?
22:42	<bakkot>	weird time
22:42	<shu>	yeah dherman saw kanye
22:43	<Rob Palmer>	kanye in a maga hat in the basement of the masonic lodge
22:44	<snek>	for stage 2
22:46	<bakkot>	syg: can you put the chartered calls in the notes
22:46	<shu>	will do now
22:58	<rickbutton>	is document.all the only web non-function object with a [[Call]]?
23:04	<apaprocki>	is document.all the only web non-function object with a [[Call]]? seems like it https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#htmlallcollection
23:09	<rickbutton>	well there could be more
23:10	<apaprocki>	no
23:10	<apaprocki>	just document.all
23:11	<rickbutton>	~~separate from that, I'm confused why `Function.prototype.bind.call(document.all).__proto__ === Object.prototype` and not `document.all.__proto__`~~
23:13	<rickbutton>	oh wait, it is
23:16	<snek>	wait document.all is also callable?
23:16	<rickbutton>	yes
23:18	<Ashley Claymore>	That’s why Leo brought that topic about if ShadowRealm should special case it
23:18	<Ashley Claymore>	As it’s callable it can go through the boundary
23:19	<Ashley Claymore>	And becomes a wrapped function on the other side
23:19	<snek>	is there a reason we don't just call it a function with a bunch of properties on it
23:19	<snek>	like yeah its missing the prototype but you can do that to a function anyway
23:19	<rickbutton>	is it the case then that all objects with [[Call]] on web are either one of the function-family (normal/async/generator) or its a HtmlAllCollection? with no exceptions
23:21	<rickbutton>	i grepped, it is the only reference to `[[Call]]` in the whole spec so I guess so yeah.
23:30	<Richard Gibson>	Michael Ficarra: I can't post in TC39 Editors for some reason, but see my response at https://github.com/tc39/ecma262/issues/2808#issuecomment-1192021230
23:39	<rickbutton>	like yeah its missing the prototype but you can do that to a function anyway it technically is a "function object" because it has [[Call]] but it isn't a built-in function exotic object