| 00:50 | <jmdyck> | in PR 2045, the built-in generator functions are inaccessible to userland, right? |
| 00:53 | <bakkot_> | jmdyck I haven't read that PR's spec text yet, but that was the plan discussed in https://github.com/tc39/proposal-iterator-helpers/issues/97#issuecomment-637833039, yes |
| 00:58 | <jmdyck> | okay, well, I'm going to have to read some stuff then, but is there a quick reason for why the built-in generator functions are functions and not abstract operations? |
| 00:59 | <jmdyck> | seems like it complicates the spec for no benefit |
| 01:07 | <bakkot_> | that I couldn't tell you; the conclusion fo the last discussion I was involved in was "Each iterator helper object will have an internal slot that contains a generator-like algorithm (an abstract closure) with "Yield" steps, something like the %SyncMap% sketch @devsnek posted in #86." |
| 01:08 | <devsnek> | jmdyck: the iterator proposal will make use of built in generators |
| 01:08 | <devsnek> | they're not very useful for the existing iterators imo but people want everything to be the same |
| 01:10 | <jmdyck> | will the iterator proposal define new built-in generator functions? |
| 01:10 | <bakkot_> | devsnek that doesn't answer the question of why they're being spec'd as actual functions though |
| 01:11 | <devsnek> | i mean i think they should be actual functions |
| 01:11 | <bakkot_> | ... why? |
| 01:11 | <devsnek> | because if i was writing them in js i would use functions |
| 01:12 | <bakkot_> | ... so? |
| 01:12 | <jmdyck> | if you were writing *anything* in js you'd use functions. |
| 01:12 | <bakkot_> | I sincerely do not understand the relevance ofo that |
| 01:13 | <devsnek> | i mean if you want to write out 22 iterator prototypes |
| 01:14 | <devsnek> | or spec the existence of suspendable abstract ops |
| 01:14 | <devsnek> | more power to you |
| 01:14 | <jmdyck> | the spec already has suspendable abstract ops, doesn't it? |
| 01:14 | <devsnek> | no |
| 01:14 | <devsnek> | the correlation to actual functions is simple because we already have them |
| 01:14 | <bakkot_> | I don't think you need to spec the existence of suspend-able abstract ops explicitly |
| 01:15 | <bakkot_> | the mechanism that `yield` uses should work just the same in AOs |
| 01:15 | <devsnek> | yield in an AO suspends the function |
| 01:15 | <devsnek> | not the AO |
| 01:16 | <devsnek> | like the boundary is the function |
| 01:16 | <devsnek> | you'd have to set up code execution state for AOs |
| 01:16 | <jmdyck> | anyhow, shifting from built-in generator functions to AOs doesn't require suspenable AOs |
| 01:16 | <devsnek> | i'm open to new ideas |
| 01:20 | <jmdyck> | the BIGF doesn't do any suspending, it basically just creates the generator object, and calls GeneratorStart on it. |
| 01:20 | <devsnek> | what's BIGF |
| 01:21 | <devsnek> | oh built in generator function |
| 01:21 | <jmdyck> | yup |
| 01:21 | <devsnek> | yeah i mean its a generator |
| 01:21 | <jmdyck> | then returns the generator object |
| 01:21 | <devsnek> | except the body is spec steps instead of js code |
| 01:22 | <jmdyck> | a BIGF isn't a generator, it's a function that returns a generator. |
| 01:23 | <devsnek> | the BIGFs that i'm talking about are actual reified functions |
| 01:24 | <jmdyck> | the BIGFs I'm talking about are the ones in PR 2045 |
| 01:25 | <devsnek> | 2045 doesn't make sense to me |
| 01:25 | <devsnek> | like adding slots to the return value implicitly and stuff |
| 01:25 | <jmdyck> | ah, well. |
| 01:25 | <jmdyck> | now we agree. |
| 01:26 | <devsnek> | what we came up with for iterator helpers is currently (i think) |
| 01:26 | <devsnek> | - BIGF is real actual function |
| 01:27 | <devsnek> | - it's not exposed directly to js (cc ljharb?) |
| 01:27 | <devsnek> | - it has next() invoked immediately to get proper access to the first yield from userland |
| 01:28 | <devsnek> | https://gc.gy/58205433.png |
| 01:28 | <devsnek> | StartIteratorMethod(F, ...) is basically `it = F(...); it.next(); return it` |
| 01:29 | <jmdyck> | as I understand it, if it has a `next()`, then it's a generator, not a generator function |
| 01:30 | <devsnek> | whatever you call `function* x() {}` |
| 01:30 | <devsnek> | it's the builtin version of that |
| 01:30 | <jmdyck> | That's a generator function, and x() is a generator, I think. |
| 01:31 | <devsnek> | might help to say "generator function" and "generator instance" |
| 01:31 | <devsnek> | a lot of people use "generator" to mean the function |
| 01:32 | <jmdyck> | that could lead to confusion all right |
| 01:33 | <devsnek> | "star-syntax generator function" and "generator-backed iterator instance" |
| 01:37 | <jmdyck> | Looks like the spec uses "generator object", "generator instance", and "generator" more-or-less interchangeably. |
| 01:37 | <jmdyck> | vs "generator function" or "generator function object" |
| 01:37 | <jmdyck> | That could stand some clean-up. |
| 02:06 | <jackworks> | devsnek: without that IteratorKind slot, built-in generators cannot be used in String@@iterator or Map@@iterator. For iterator helper proposal, you can omit that slot and everything works fine |
| 02:08 | <jackworks> | I use "generator" to refer "function*" and "iterator" to its return value 🤔 |
| 04:18 | <devsnek> | is "Contains await" in the tla spec defined anywhere |
| 04:21 | <bakkot_> | devsnek: https://tc39.es/ecma262/#sec-static-semantic-rules |
| 04:21 | <bakkot_> | "Unless otherwise specified every grammar production alternative in this specification implicitly has a definition for a static semantic rule named Contains which takes an argument named symbol whose value is a terminal or nonterminal of the grammar that includes the associated production." |
| 04:22 | <devsnek> | does that break through function boundaries |
| 04:22 | <devsnek> | it looks like it does |
| 04:23 | <bakkot_> | no, the functions all have an override which stops it from going through them |
| 04:23 | <bakkot_> | e.g. https://tc39.es/ecma262/#sec-function-definitions-static-semantics-contains |
| 04:23 | <devsnek> | oh interesting, ok |
| 04:27 | <bakkot_> | someday I will make that Contains link |
| 04:27 | <devsnek> | we need an AI to just automatically link everything that makes sense to be linked |
| 13:56 | <devsnek> | bradleymeck: why do compartments have a module map |
| 13:56 | <devsnek> | that's a much stronger requirement on caching than the spec has |
| 13:57 | <bradleymeck> | devsnek: essentially because they are where people wanted to put all the host hooks, so moving the map so that compartments can resolve on their own scope rather than the realm |
| 13:57 | <devsnek> | the host hook can still be scoped to the compartment |
| 13:58 | <bradleymeck> | devsnek: the spec is very loose in its requirements yea, but for things like cyclic linkage you need some way to coordinate |
| 13:58 | <bradleymeck> | devsnek: maybe i don't understand the question |
| 13:58 | <bradleymeck> | devsnek: what is the concern with compartments having a map |
| 13:58 | <devsnek> | well not just maps |
| 13:59 | <devsnek> | the import/importNow/module apis are weird to me |
| 13:59 | <bradleymeck> | we all agree on that |
| 13:59 | <devsnek> | if you desire to store your modules by something more than (referrer, specifier) i would say you should bring your own map |
| 13:59 | <devsnek> | like how we bring our own module map in nodejs's loader |
| 14:00 | <bradleymeck> | moduleMap is a way to initialize things, not a true store |
| 14:00 | <devsnek> | initialize what |
| 14:01 | <devsnek> | some default hostresolveimportedmodule hook that uses moduleMap? |
| 14:01 | <bradleymeck> | referrer / callsite is how the spec mandates stuff idk what you mean. you must have some referrer/callsite storage |
| 14:01 | <devsnek> | like literally the api that v8 has |
| 14:01 | <devsnek> | modulo the complexity of ScriptOrModule classes |
| 14:01 | <devsnek> | why is it not that |
| 14:02 | <bradleymeck> | i don't understand your question, this about making sure we have hooks enforce spec not the v8 API |
| 14:02 | <devsnek> | right the v8 api doesn't put additional behaviour in |
| 14:02 | <devsnek> | its just the spec |
| 14:02 | <devsnek> | but "moduleMap" is new |
| 14:02 | <bradleymeck> | moduleMap is helpful to initialize without creating new module instances |
| 14:02 | <devsnek> | i don't understand what it initializes |
| 14:02 | <bradleymeck> | you *could* wire it up yourself |
| 14:03 | <bradleymeck> | it is just initializing what the default resolve will preempt |
| 14:03 | <bradleymeck> | if it is empty, it always calls the hook |
| 14:03 | <devsnek> | that seems weird |
| 14:03 | <bradleymeck> | if it isn't empty it preempts to those values |
| 14:03 | <devsnek> | library territory i guess |
| 14:03 | <bradleymeck> | see moddable's impl that has a similar API |
| 14:03 | <devsnek> | the use case isn't weird but it being in js is weird |
| 14:03 | <devsnek> | if that makes sense |
| 14:04 | <bradleymeck> | at this point JS is just JS to me and I have few questions |
| 14:04 | <devsnek> | well i can open a more in depth issue i guess |
| 14:04 | <bradleymeck> | sure |
| 14:05 | <bradleymeck> | i haven't found enough time for compartments with all the other meetings i've been drowning in |
| 14:05 | <devsnek> | is there a better person to ping on questions like this |
| 14:28 | <bradleymeck> | devsnek: kris kowal likely, though hes been touching that repo more than I |
| 14:28 | <bradleymeck> | realms stuff about push back there is a bit more front and center currently for me |
