2021-10-01 [17:00:01.0754] we're moving progressively further in that direction with our internal tooling and it's been basically fine [17:00:34.0404] you need to do some basic conservative type analysis but at least in the code I've been working with that type analysis is feasible [17:01:30.0942] I absolutely don’t agree. Even with a full type system, the difficulty of banning `Nodelist.p.forEach` had lead to bugs for us. [17:02:05.0437] As soon as you cast to avoid a typecheck, we get ambiguities that let it slip back in [17:02:46.0763] Even with a type system and full typing, it’s a difficult problem [17:03:34.0053] Requiring us to rewrite tooling infra on top of another’s type system seems bad. [17:04:26.0200] Devirtualized methods are simple, tiny, fast, and extremely easy to tree shake statically [17:43:38.0070] * Requiring us to rewrite tooling infra on top of another’s type system (even if it's as beloved as TS) seems bad. [17:43:57.0702] * Devirtualized methods are simple, fast, and extremely easy to tree shake statically [18:09:11.0337] rkirsling: actually pun was not intended! [18:26:35.0026] Concerning proposed Partial Function Application, should partially applying `import()`work? [21:42:06.0211] The import() function is just an ordinary function, yeah? Nothing special syntactically? [21:42:18.0554] Assuming that's true, then yeah [21:56:11.0629] no, it is a special syntactic form, not a function [21:56:29.0805] (it has to be, since it's module-relative - it's not something you could coherently pass around) [00:12:20.0999] jschoi: maybe the readme could say how it differs from the `::` bind proposal? Unless maybe it is already obvious and I am just being slow [00:17:16.0743] * jschoi: maybe the readme could say how it differs from the `::` bind proposal? Unless maybe it is already obvious and I am just being slow. Or is it just that there is nothing stopping there being similar proposals, lead by different groups of people? Healthy competition type of thing? [04:24:46.0158] > <@aclaymore:matrix.org> jschoi: maybe the readme could say how it differs from the `::` bind proposal? Unless maybe it is already obvious and I am just being slow. Or is it just that there is nothing stopping there being similar proposals, lead by different groups of people? Healthy competition type of thing? Yeah, good idea. The new proposal is pretty much the same as the old bind proposal except it has no unary form. Michael has recommended to open a new repository because of the baggage with the old proposal in https://github.com/tc39/proposal-bind-operator/issues/56#issuecomment-698444297. There’s also a Gist comparing the new proposal with the Stage-1 Extensions proposal, but it focuses on security rather than “call/bind are common”, so it’s out of date. I plan to edit it and add it to the repository later. https://gist.github.com/js-choi/eca7c67f88a2e82c3353fb11e8da46f7 [05:52:34.0745] thanks for that info jschoi ! 2021-10-02 2021-10-04 [08:43:20.0818] I made a [TypeScript PR](https://github.com/microsoft/TypeScript/pull/37973) for the new Syntatic Marker variant of Partial Application proposal. There's a [Playground link](https://www.staging-typescript.org/play?ts=4.5.0-pr-37973-15#code/PTAEAUBsEME8HMBOB7ArgOwCagGbMRNIgC4CW0koAggA42SkDG0Zy6oAFscTQM4BcIeKWIdUAIwB0jZAFtgxRgGYAnMBooayXhQC0NImT3Q6DZq3QAoEKAAqsGgFMAyo0SkaxCACV+nbnyCwMKiEtJywLJMKLzIOMTA9k6u7p7qqJCQwEoA7Co5StZgzqh0+MS8oOLIorgAFAD8ADSgAIwAlKDQWLgAfo0tHaC6eIiyvJJF1KRR6PCgxMigvADuIowcpHMLS1w8AkIiYlIy8oqq6praegYk5JC6JvRMLKRswKS8vKiOvMAALAAOYYANyI5HQXjioA0yC0OkosTYkxsAFloFtQFEvlt5lotl5GKhEIhHJDILBQJ8YYZ7hSuqZYLjQJJWcNSbwvLdoLJHMRHIhJpYZOhOcsAI6oIiOUAAXlA6NEki0K36zVAACZ2gBuSzCtixSCOSSQZDwOq8SXSur-do6yxAA) for it too! Test it out! [08:44:20.0190] Partial application on generics? [08:44:32.0687] Oh on values Cool [08:45:20.0127] * I made a [TypeScript PR](https://github.com/microsoft/TypeScript/pull/37973) for the new [Syntatic Marker variant of Partial Application proposal](https://github.com/tc39/proposal-partial-application/issues/48). There's a [Playground link](https://www.staging-typescript.org/play?ts=4.5.0-pr-37973-15#code/PTAEAUBsEME8HMBOB7ArgOwCagGbMRNIgC4CW0koAggA42SkDG0Zy6oAFscTQM4BcIeKWIdUAIwB0jZAFtgxRgGYAnMBooayXhQC0NImT3Q6DZq3QAoEKAAqsGgFMAyo0SkaxCACV+nbnyCwMKiEtJywLJMKLzIOMTA9k6u7p7qqJCQwEoA7Co5StZgzqh0+MS8oOLIorgAFAD8ADSgAIwAlKDQWLgAfo0tHaC6eIiyvJJF1KRR6PCgxMigvADuIowcpHMLS1w8AkIiYlIy8oqq6praegYk5JC6JvRMLKRswKS8vKiOvMAALAAOYYANyI5HQXjioA0yC0OkosTYkxsAFloFtQFEvlt5lotl5GKhEIhHJDILBQJ8YYZ7hSuqZYLjQJJWcNSbwvLdoLJHMRHIhJpYZOhOcsAI6oIiOUAAXlA6NEki0K36zVAACZ2gBuSzCtixSCOSSQZDwOq8SXSur-do6yxAA) for it too! Test it out! 2021-10-05 [16:19:57.0294] If we were to guess which standard functions do developers most commonly use explicitly, among all JavaScript code, then what would those functions be? `console.log`? `Array.prototype.push`? `Function.prototype.call`? `Array.from`? [16:20:30.0075] `Array.map` [16:20:47.0892] * Array.map [16:20:55.0784] * `Array.map` [16:22:13.0828] Indeed, when I count occurrences in Gzemnid’s dataset of top-1000 downloaded NPM packages in 2019-09, then I get the following results: ```bash > ls search.topcode.sh slim.topcode.1000.txt.lz4 > ./search.topcode.sh '\b.map\b' | awk 'END { print NR }' 1016503 > ./search.topcode.sh '\.call\b' | awk 'END { print NR }' 500084 > ./search.topcode.sh '\bconsole.log\b' | awk 'END { print NR }' 271915 > ./search.topcode.sh '\.apply\b' | awk 'END { print NR }' 225315 > ./search.topcode.sh '\.bind\b' | awk 'END { print NR }' 170248 > ./search.topcode.sh '\.set\b' | awk 'END { print NR }' 168872 > ./search.topcode.sh '\.push\b' | awk 'END { print NR }' 70116 ``` [16:24:22.0849] Obviously though these are only rough surrogates for the actual total JavaScript codebase of humankind. [16:24:31.0844] * Obviously though these are only rough surrogates for the actual total JavaScript codebase of humankind. [16:25:00.0302] I don't trust minimized/transpiled code as much tho. It's no exactly what people write. [16:26:33.0410] As far as I can tell, Gzemnid tries to exclude minified code (https://github.com/nodejs/Gzemnid/blob/main/README.md#deception), although it has lots of other limitations… [16:27:06.0717] I don’t think the “slim” in the filename means minified. I think it means LZ4 compressed. [16:27:27.0317] There’s `slim.code.coffee.txt.lz4` and `slim.code.ts.txt.lz4` too. [16:27:38.0731] * I don’t think the “slim” in the filename means minified. It means LZ4 compressed. [16:28:05.0457] * I don’t think the “slim” in the filename means minified. I think means LZ4 compressed. [16:28:08.0638] * I don’t think the “slim” in the filename means minified. I think it means LZ4 compressed. 2021-10-06 [17:24:54.0948] I highly, highly doubt `.call` is actually used that much in real code. It might be counting library code a bunch? [17:25:38.0740] > <@tabatkins:matrix.org> I highly, highly doubt `.call` is actually used that much in real code. It might be counting library code a bunch? I actually checked the first thousand lines of its output and they all generally seem legitimate to me. [17:25:48.0641] I can dump them in a Gist. [17:26:39.0453] Mostly stuff like `_super.call(this, destination)` or `tryCatch(onCancelCallback).call(this._boundValue())`. [17:27:08.0466] Oh, you’re asking if it’s double-counting dependencies. [17:27:48.0504] I don’t…think it should… [17:28:32.0281] I’ll check with `uniq`. [17:40:14.0322] Sorting the output then running `uniq -d` doesn’t return any duplicate lines. It doesn’t seem to be double-counting dependencies. At most, a library might manually include the code of another library in its own source code, but that problem is probably pretty small. And it applies to all the other functions’ counts, too. [17:53:53.0630] …I’d upload the sorted dump, but I just realized not everyone might want to download a 75.9-MB file, and I don’t know how Matrix’s file sharing works, haha. [17:59:49.0663] (Fun fact: The most-downloaded NPM library that uses `.call`, as of 2019-09, was debug, and it uses `.call` twice: in `createDebug.formatArgs.call(self, args)` and in `match = formatter.call(self, val);`.) [18:00:42.0866] (Next up is kind-of, which uses `.call` once, followed by readable-stream…which uses `.call` nineteen times.) [18:12:58.0457] * (Next up is kind-of, which uses `.call` once, followed by readable-stream…which uses `.call` nineteen times. And lodash uses `.call` 127 times.) [21:32:19.0342] jschoi: https://sourcegraph.com/search?q=context:global+.call%28+lang:javascript&patternType=literal [22:21:32.0617] Is there a place to follow what is outstanding on https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs? There was a GitHub repo at some point... [23:27:58.0522] /me finds https://github.com/linuxwolf/bmeck-ids [23:58:51.0050] > <@devsnek:matrix.org> jschoi: https://sourcegraph.com/search?q=context:global+.call%28+lang:javascript&patternType=literal Excellent, thank you. Though it doesn’t seem to quantify results (“500+ results”), this will still be very useful…It sure seems a lot better than GitHub’s code search; that’s for sure. [09:20:30.0255] Ashley Claymore: I think it would be incorrect to call a Symbol's [[Description]] an internal slot. It's just something else ("an associated value") that happens to use the same metasyntax. [09:30:18.0554] thanks :D [09:37:58.0444] When Symbols were first introduced in the early drafts of ES 6, they were a kind of exotic object, so at that time, [[Description]] *would* have been an internal slot, except that by the time [[Description]] showed up, Symbols had already changed to be a new kind of primitive. [09:47:18.0824] ah - that's an interesting bit of history [11:13:29.0344] does anyone have any background reading on the discussion from last week, that pipeline-operator and call-this are the future of writing tree-shakeable code? I would like to understand this better [14:14:33.0524] jmdyck: symbol descriptions are 100% an internal slot, and the getter works across realms [14:14:52.0894] unless you're saying primitives can't have one and that's the fudge factor? [16:49:06.0980] @ljharb: I wouldn't say that primitives *can't* have internal slots, rather that the spec doesn't describe them as having internal slots. The spec talks about 'internal slots' only in connection with objects, and in particular does not describe a Symbol's [[Description]] as an 'internal slot'. So calling it an internal slot isn't supported by the spec. [16:49:21.0036] hm [16:49:38.0820] i mean, it has the same semantics. and on boxed symbol objects it acts just like an internal slot too. [16:55:36.0689] I don't think the spec has such a thing as boxed symbol objects. You mean like Number Objects and String Objects? [16:57:51.0298] Like, a Number Object is an object-box around a Number value? I don't think there's a similar object-box for Symbol values. [16:58:46.0331] jmdyck: there is, see 20.4 [16:58:48.0340] * jmdyck: there is, see 20.4 [16:59:13.0451] or I guess better see Table 18 for Symbol [16:59:20.0195] https://tc39.es/ecma262/multipage/abstract-operations.html#table-toobject-conversions [16:59:24.0141] that returns "a new Symbol value", not an object [16:59:48.0047] ToObject applied to Symbol says "Return a new Symbol object whose [[SymbolData]] internal slot is set to argument." 2021-10-07 [17:00:01.0800] and indeed `typeof Object(Symbol()) === 'object'` [17:00:22.0563] ah, there it is, thanks. [17:00:59.0367] I'm going to have to look at this more. [17:01:36.0709] however, boxed symbols do not have a [[Description]] internal slot [17:02:13.0800] they instead have a [[SymbolData]] internal slot, which holds the underlying symbol, which is what e.g. `Symbol.prototype.description` uses [17:06:01.0057] So it looks like the only way to create a Symbol object is by invoking ToObject on a Symbol value. Is that right? [17:11:48.0486] (e.g., there isn't an analogue to `new Number(3)`) [17:18:00.0187] afaik yes [17:18:05.0581] same deal for BigInts, I think [17:19:54.0936] And referring to `Symbol()` as "the Symbol constructor" is technically correct, but maybe misleading (same with BigInt). [17:28:25.0080] i.e., it has a [[Construct]] internal method so satisfies the definition of "constructor", but if you invoke it, you just get a TypeError, same as if it didn't have a [[Construct]] method, so it's kinda tenuous to call it a constructor? [17:33:32.0155] It looks like `Symbol()` and `BigInt()` are the only things described as constructors that nevertheless are "not intended to be used with the `new` operator". [17:33:47.0212] * It looks like `Symbol()` and `BigInt()` are the only things described as constructors that nevertheless are "not intended to be used with the `new` operator". [17:40:38.0782] true, but otoh it's the only way I've ever heard anyone refer to it, so I'd be reluctant to change it [17:41:45.0145] huh, interesting. [09:11:30.0196] it starts with a capital letter and its .prototype is the [[Prototype]] of the instances, that colloquially makes it the constructor even if you can’t new it [09:12:09.0412] All the DOM element constructors can’t be newed either, and they’re all still called constructors [09:12:22.0812] I think of it as a 'newless constructor' [09:14:19.0121] or a standard constructor like `Number`, except that if I try and create a Number object instance it very loudly says "I'm not sure you want to do that" [09:14:35.0562] s/Number/Symbol/ [09:16:38.0251] maybe in the future if there was ever direct support for `#constructor` then could say that's what is happening in the case of `Symbol` and `BigInt` [16:14:58.0123] Does anyone know why the following syntax was not included when getters/setters were added? And has it ever been proposed? ``` const getFoo = () => foo; obj = {get foo: getFoo}; ``` [16:15:10.0719] * Does anyone know why the following syntax was not included when getters/setters were added? And has it ever been proposed? ``` const getFoo = () => foo; const obj = {get foo: getFoo}; ``` [16:16:26.0956] Alternative is to jump through `defineProperty` hoops, which is not very ergonomic (and hard to type right in TypeScript) 2021-10-08 [23:59:25.0971] Maybe the assumption is that the majority of getter/setter implementations would be based on the receiver? [00:03:23.0663] There was some discussion here recently https://es.discourse.group/t/allow-arrow-functions-getters/930/4 [00:05:24.0902] i mean, my personal opinion, and that of a number of styleguides, is that getters and setters are gross and should be avoided :-) that doesn't at all answer your question ofc, but it may be relevant if there were a proposal to make using getters easier. 2021-10-11 [06:57:33.0654] Does anyone know why `BigInt.asIntN` is a static method? `BigInt.asIntN(8, 1234n)` and not `1234n.asIntN(8)` [06:57:39.0541] * Does anyone know why `BigInt.asIntN` is a static method? `BigInt.asIntN(8, 1234n)` and not `1234n.asIntN(8)` 2021-10-13 [17:26:47.0172] is there a transform for the current decorator proposal yet [20:56:09.0729] devsnek: https://javascriptdecorators.org/ exists, though I don't think it has perfect fidelity [07:15:05.0323] The Babel plugin will probably be released around the end of the year (we have a minor release every two months, and the transform is not ready yet for the next minor) [07:15:13.0975] > <@devsnek:matrix.org> is there a transform for the current decorator proposal yet * The Babel plugin will probably be released around the end of the year (we have a minor release every two months, and the transform is not ready yet for the next minor) [08:00:40.0718] honestly i don't think anyone would complain if decorating a function made it not hoist [08:39:37.0752] I would? Not hoisting is really annoying in non-trivial files, since it means the contents of your functions imposes an ordering on the functions themselves. [08:40:13.0965] It's why I almost never do the `const fn = x=>...;` thing that all the kids are doing these days. [12:06:38.0839] TabAtkins: a lot of people order stuff by use [12:06:48.0060] i think the two most popular eslint configs enforce that [12:07:05.0652] and it would only happen if you decorated something [12:09:10.0842] also how often do you need the pre-evaluate hoisting? even if stuff is out of order without the hosting it generally works at runtime cuz its after all the definitions are evaluated [12:28:38.0197] const/let impose a lexical tdz tho, so things preceding them that make reference to the binding can't find them, right? or do they capture a lexical ref and only complain if it's actually executed before hitting the variable def? [12:28:52.0977] it's been a while since i've run into issues, I just remember having problems at some point. [12:29:39.0898] TabAtkins: this code works ```js const a = () => b; const b = 2; a(); ``` [12:30:25.0719] okay, i don't remember the issues i've run into in the past, then [12:30:50.0448] the case that breaks is if you call `a()` before `const b = 2` [12:30:54.0846] which i think is [12:30:57.0632] exceedingly rare code [12:31:53.0739] i suspect it might have been something like starting a rAF() loop by calling the function immediatley after defining it, and then it blowing up because it depended on functions defined later in the file with const [12:32:12.0146] ah that sounds like smth that could happen [12:32:25.0810] but if you did update your raf code to use a decorator you could always adjust the call order :P 2021-10-14 [17:49:11.0507] Hmm. I though about it a bit and making a transformer for decorated hoisted functions sounds a bit tricky. The transformer might need to put all the decorating code inside a hoisted function for it to work the same, and then might have to capture `arguments` and `this` for use in the decorated function body. [20:00:37.0437] my suggestion is to turn `@foo function bar() {}` into `var bar = foo(function bar() {}, { kind: 'function', name: 'bar' });` [20:00:48.0806] annex b.3.3 aside [20:02:54.0273] * my suggestion is to turn `@foo function bar() {}` into `var bar = foo(function bar() {}, { kind: 'function', name: 'bar' });` [02:45:25.0628] Many spec algorithms seem to call a `Completion(...)` abstract operation (for example in https://tc39.es/ecma262/#sec-iteratorclose), but I cannot find where it is defined. Is it a type cast to convert a record into a completion record? [03:03:24.0387] > <@nicolo-ribaudo:matrix.org> Many spec algorithms seem to call a `Completion(...)` abstract operation (for example in https://tc39.es/ecma262/#sec-iteratorclose), but I cannot find where it is defined. Is it a type cast to convert a record into a completion record? Oh it's defined at https://tc39.es/ecma262/#sec-implicit-completion-values - It looks like there is an auto-linking issue that links usages of the `Completion` AO to the `Completion` record definition rather than to the AO definition [09:32:14.0240] nicolo-ribaudo: linking should be fixed in this PR: https://github.com/tc39/ecma262/pull/2547/files#diff-181371b08d71216599b0acccbaabd03c306da6de142ea6275c2135810999805aR832 [10:33:30.0465] ooh, that sounds like a great PR [10:38:11.0844] annevk: unfortunately it's a TON of work, so it'll be at least another few weeks before it's done [10:49:04.0306] I can only imagine [10:49:53.0925] Might have some downstream implications too, but hopefully not too many [10:52:08.0457] probably a lot of stray `!`s in HTML to remove, mainly [10:53:55.0856] specifically, I think other specs don't tend to make use of the implicitness of completion records much (or at all?), so the relevant change is just that algorithms which were guaranteed to succeed no longer return completion records and hence no longer need to be unwrapped with `!` [11:08:15.0966] bakkot: we do create a Completion record somewhere [11:08:59.0584] Removing ! sounds amazing, has caused quite a bit of confusion over the years [11:09:22.0672] Feels like every couple months there's someone asking why it's negating something [11:12:22.0456] there will still be some `!`s, for operations which normally can throw but which don't in this particular instance [11:12:36.0630] but I think a majority of them will be removed [11:14:45.0649] I see, we do have some of those as well 2021-10-16 [07:14:03.0571] If anyone has any grammar suggestions with regards to https://github.com/js-choi/proposal-bind-this/issues/14#issuecomment-944697033 (how we could loosen the bind-`this` operator such that `a.b::c.d()` would unambiguously parse as `(a.b)::((c.d)())` and not `((a.b)::(c.d))()` or `((a.b)::c).d)()`), please let me know on the issue. I’m kind of stumped: for any recursive production I can think of that would cover `a.b::c.d`, that production would also cover `a.b::c`… [07:14:36.0545] * If anyone has any grammar suggestions with regards to https://github.com/js-choi/proposal-bind-this/issues/14#issuecomment-944697033 (how we could loosen the bind-`this` operator such that `a.b::c.d()` would unambiguously parse as `(a.b)::((c.d)())` and not `((a.b)::(c.d))()` or `((a.b)::c).d)()`), please let me know on the issue. I’m kind of stumped: for any recursive production I can think of that would cover `a.b::c.d`, that production would also cover `a.b::c`… [07:49:10.0579] I can see why the third parse isn't useful (tho I think it's what I would naively expect, treating :: as an alternative dot), but I'm not sure why you'd want the first parse over the second. [07:49:45.0413] It doesn't seem like it's what rbuckton is asking for in that issue, either [08:31:49.0511] * If anyone has any grammar suggestions with regards to https://github.com/js-choi/proposal-bind-this/issues/14#issuecomment-944697033 (how we could loosen the bind-`this` operator such that `a.b::c.d()` would unambiguously parse as `((a.b)::(c.d))()` and not `(a.b)::((c.d)())` or `((a.b)::c).d)()`), please let me know on the issue. I’m kind of stumped: for any recursive production I can think of that would cover `a.b::c.d`, that production would also cover `a.b::c`… [08:33:31.0218] TabAtkins: Yeah, sorry, I meant to make the goal grouping `((a.b)::(c.d))()` and not `(a.b)::((c.d)())`; I’ve edited my message. The problem is that I can’t figure out how I’d make a grammar that makes `…::…` looser than `….…` while making `…::…` still as tight as `…(…)`. [08:33:50.0651] * TabAtkins: Yeah, sorry, I meant to make the goal grouping `((a.b)::(c.d))()` and not `(a.b)::((c.d)())`; I’ve edited my message. The problem is that I can’t figure out how I’d make a grammar that makes `…::…` looser than `….…` while making `…::…` still as tight as `…(…)`. [08:35:28.0821] fwiw while i think `a::Array.prototype.map` is nice, 100% of the actual use cases i have all involve caching the method beforehand, so `a::(Array.prototype.map)` doesn’t seem that bad, if you can’t figure out a solution. [08:42:52.0325] * If anyone has any grammar suggestions with regards to https://github.com/js-choi/proposal-bind-this/issues/14#issuecomment-944697033, please let me know on the issue. That is, I’m stumped on how we could loosen the bind-`this` operator such that `a.b::c.d()` would unambiguously parse as `((a.b)::(c.d))()` (that issue’s goal) and not `(a.b)::((c.d)())` (useless) or `((a.b)::c).d)()` (the current behavior). For any recursive production I can think of that would cover `a.b::c.d`, that production would also cover `a.b::c`… [08:44:06.0765] * If anyone has any grammar suggestions with regards to https://github.com/js-choi/proposal-bind-this/issues/14#issuecomment-944697033, please let me know on the issue. That is, I’m stumped on how we could loosen the bind-`this` operator such that `a.b::c.d()` would unambiguously parse as `((a.b)::(c.d))()` (that issue’s goal) and not `(a.b)::((c.d)())` (useless) or `((a.b)::c).d)()` (the current behavior). For any recursive RHS production I can think of that would cover `c.d`, that production would also cover `c` and/or `c.d()`… [08:44:39.0484] * If anyone has any grammar suggestions with regards to https://github.com/js-choi/proposal-bind-this/issues/14#issuecomment-944697033, please let me know on the issue. That is, I’m stumped on how we could loosen the bind-`this` operator such that `a.b::c.d()` would unambiguously parse as `((a.b)::(c.d))()` (that issue’s goal) and not `(a.b)::((c.d)())` (useless) or `((a.b)::c).d)()` (the current behavior). For any recursive production I can think of that would cover `c.d`, that production would also cover `c` and/or `c.d()`… [08:52:15.0731] If we do end up figuring out how to make `a.b::c.d()` unambiguously group as `((a.b)::(c.d))()`, then I think that RHS chain-of-property-identifiers expression is similar enough to decorators’ syntax that they should share a production, named something like SimpleMemberExpression. [08:52:49.0896] * If we do end up figuring out how to make `a.b::c.d()` unambiguously group as `((a.b)::(c.d))()`, then I think that RHS chain-of-property-identifiers expression is similar enough to decorators’ syntax that they should share a production, named something like SimpleMemberExpression. [09:42:02.0713] Maybe change CoverCallExpressionAndAsyncArrowHead to be SomethingExpression Arguments, then define SomethingExpression to be `MemberExpression` or `MemberExpression :: MemberExpression` [09:43:54.0740] * Maybe change CoverCallExpressionAndAsyncArrowHead to be SomethingExpression Arguments, then define SomethingExpression to be `MemberExpression` or `MemberExpression :: MemberExpression` [09:46:08.0881] * Maybe change CoverCallExpressionAndAsyncArrowHead to be `SomethingExpression Arguments`, then define SomethingExpression to be `MemberExpression` or `MemberExpression :: MemberExpression` [09:47:07.0563] I think I'm with ljharb on this: if you're not caching the functions into an ident, you're really losing the semantic connection with foo.bar() syntax, and might as well just be writing the function to take the value as a first arg instead [09:51:15.0847] (I'm still not quite convinced :: pulls its weight, with `foo.bar~()` solving the auto-bind case and pipeline making it easy to linearize. All that's left is this "rip off methods and call them on something else" case, and honestly `const map = Array.prototype.map.call~(...)` solves that well enough imo.) [09:55:35.0594] That presumes PFA pulls its weight tho for non-bind use cases, which I’m not convinced on. [10:46:04.0890] Sure. But between the two, they cover a total of four major use-case categories (implicit binding, fluent importable methods, partial application, tear-off methods). PFA covers 1, 3, and does 4 reasonably well (with pipeline covering 2 and the rest of 4), while bind-op covers 1, 2 (if you import them as plain names, or we solve the parsing issues), and 4, with nothing else covering 3. [10:47:53.0445] Plus bind-op, by covering 2, overlaps with pipeline (and somewhat also in 4). [10:48:20.0819] So, looking at these just as lego blocks we want to jam together, I'm finding PFA+pipeline a wider, more efficient cover for the use-cases than bind-op. [10:51:49.0436] I also think PFA has a nicer "single story to tell" - it does one thing and does it well; all the use-cases it covers are obvious realizations of that one thing (binding arguments to a call ahead of time). Bind-op can be seen as doing one thing (binding the receiver for a function, which may or may not be immediately called), but in practice its uses are _thematically_ linked but _practically_ distinct - implicit binding and fluent/tear-off invocations are completely different usage patterns. [10:51:52.0509] * (I also think PFA has a nicer "single story to tell" - it does one thing and does it well; all the use-cases it covers are obvious realizations of that one thing (binding arguments to a call ahead of time). Bind-op can be seen as doing one thing (binding the receiver for a function, which may or may not be immediately called), but in practice its uses are _thematically_ linked but _practically_ distinct - implicit binding and fluent/tear-off invocations are completely different usage patterns.) [10:51:56.0735] * I also think PFA has a nicer "single story to tell" - it does one thing and does it well; all the use-cases it covers are obvious realizations of that one thing (binding arguments to a call ahead of time). Bind-op can be seen as doing one thing (binding the receiver for a function, which may or may not be immediately called), but in practice its uses are _thematically_ linked but _practically_ distinct - implicit binding and fluent/tear-off invocations are completely different usage patterns. [10:56:20.0419] * Sure. But between the two, they cover a total of four major use-case categories (implicit binding, fluent importable methods, partial application, tear-off methods). PFA covers 1, 3, and can pretty easily convert 4 into 2 (with pipeline covering 2 and the rest of 4), while bind-op covers 1, 2 (if you import them as plain names, or we solve the parsing issues), and 4, with nothing else covering 3. [13:11:47.0022] Looking at the results of https://github.com/js-choi/proposal-bind-this/issues/12, I don’t think most current uses of `.call` (which is extremely common) would be improved with PFA syntax. [13:12:12.0123] * Looking at the results of https://github.com/js-choi/proposal-bind-this/issues/12, I don’t think most current uses of `.call` (which is extremely common) would be improved with PFA syntax. [13:12:41.0240] I will try to make this clear in the slides, although I don’t think that this concern should block Stage 1 anyway. [16:00:15.0970] i think trying to figure out the right syntax is kind of a red herring here [16:00:25.0048] because you should definitely 100% use parens when writing that code 2021-10-17 [17:27:02.0473] For what it’s worth, I did figure out a grammar that I think unambiguously loosens the operator to be looser than `….…` and `new …(…)` but tighter than `…[…]`, `…(…)`, `…?.…`, and `new …`. (`new a::b()` would be a SyntaxError.) [17:27:36.0040] * For what it’s worth, I did figure out a grammar that I think unambiguously loosens the operator to be looser than `….…` and `new …(…)` but tighter than `…[…]`, `…(…)`, `…?.…`, and `new …`. (`new a::b()` would be a SyntaxError.) [17:30:24.0730] Also: so much for the next plenary’s agenda being light. https://github.com/tc39/agendas/blob/master/2021/10.md [17:30:35.0436] * Also: so much for the next plenary’s agenda being light. [17:34:56.0468] * Also: so much for the next plenary’s agenda being light. https://github.com/tc39/agendas/blob/master/2021/10.md 2021-10-18 [09:14:54.0153] I think I'm leaning strong into the "not worth trying, just stick to an ident" camp, because :: is meant to be "like ., but the obj and function don't have to be previously related", and the more we move away from that the more confusing it'll get. [09:15:33.0632] Plus `a1.a2::a3.a4::a5.a6()` is ????? [09:15:49.0041] well formed 😄 [09:16:47.0667] i recognize that it's purely a dot-call operator, and so one *can* argue that any expression that's *not* of the form `::foo()` is clearly doing something different, but I'm not sure about that. [09:19:21.0199] like what if `foo::bar`, without parens, invoked it like a getter setter [09:19:59.0099] ...wait, what happens when you say `foo.bar.baz = 3` and both .bar and .baz are getter/setter pairs [09:28:12.0027] yeah it calls the .bar getter and the .baz setter, that's what i would expect [09:40:18.0111] okay raised https://github.com/js-choi/proposal-bind-this/issues/17 about it; realized while writing it that WeakMaps-as-ephemerons are the most obvious use-case. [10:02:28.0585] So there could be a way to do this: `map::key ??= defaultValue` that’s kinda interesting [10:08:55.0599] 😱 [10:08:56.0805] I think atm if someone wanted this they would do something that ends up looking like `ref(map, key).v ??= defaultValue` [10:10:59.0914] > <@aclaymore:matrix.org> So there could be a way to do this: > > `map::key ??= defaultValue` > that’s kinda interesting More like `key::map ??= defaultValue`, otherwise you have to write the implementation in `key` instead of in `map` [10:20:47.0712] The issue suggests that a :: get/set is treated differently from a call. So the get/set logic comes from the lhs using the rhs as a param [10:24:22.0441] Hang on, I did get it wrong way round [10:26:32.0862] Yes, wrong way round. [10:27:07.0030] We just don't have a way to *declare* that something is a "getter fn", so the RHS would have to, like, use a Symbol to declare it's usable as a bind-getter or bind-setter [10:27:41.0253] `class Ephemeron extends WeakMap { [Symbol.bindGet]() { ...} }` [10:28:20.0767] the point of weakmaps as ephemerons is letting you attach "properties" to objects in ways that the objects (or anyone else) can't observe on their own [10:29:09.0228] * `class Ephemeron extends WeakMap { [Symbol.bindGet]() { ...} }` [10:29:24.0359] oh lol markdown links really intersect with symbol-keyed methods in a bad way if you don't wrap them in a code span ^_^ [10:37:12.0661] So `a.b` is call [[get]] on deref(a) with toStringOrSymbol(deref(b)). and `a::b` is call Symbol.bindGet on deref(a) with the value of deref(b). [10:37:49.0878] * So `a.b` is call [[get]] on deref(a) with toStringOrSymbol(deref(b)). and `a::b` is call Symbol.bindGet on deref(a) with the value of deref(b). [10:38:57.0313] no [10:38:57.0807] and `a::b()` is call deref(b) with a as this [10:39:52.0390] or, well, i'm unclear on exactly the mechanics you're implying by that second one. i wrote up a possible code example in https://github.com/js-choi/proposal-bind-this/issues/17#issuecomment-946005508 [10:40:28.0778] okay, reading more closely, yeah, you've still got it backwards [10:40:44.0597] the bindGet has to live on b, and be called with a [10:41:07.0555] same as the "bindCall" lives on b and is called with a in `a::b()` [10:41:37.0969] ("bindCall" just being the unforgable version of `b.call()`) [10:43:57.0582] basically if, instead of thinking of `a::b()` as "call `b()` with `a` bound to its `this`)" you think of it as "call `b.call()` with `a` as its first argument", then `a::b` is exactly the same with `b[Symbol.bindGet]` and `b[Symbol.bindSet]` [10:44:56.0109] My mind has clicked into place now thanks! [10:45:47.0824] * basically if, instead of thinking of `a::b()` as "call `b()` with `a` bound to its `this`)" you think of it as "call `b.call()` with `a` as its first argument", then `a::b` is exactly the same with `b[Symbol.bindGet]()` and `b[Symbol.bindSet]()` [10:47:18.0384] a::b() looks up [[call]] on b so can’t be intercepted. But get/set would be symbol based so more opportunity for meta-programming [10:48:25.0206] * So `a.b` is call [[get]] on deref(a) with toStringOrSymbol(deref(b)). and ~`a::b` is call Symbol.bindGet on deref(a) with the value of deref(b)~. [10:48:39.0768] * So `a.b` is call [[get]] on deref(a) with toStringOrSymbol(deref(b)). and ~~`a::b` is call Symbol.bindGet on deref(a) with the value of deref(b)~~. [10:49:04.0856] * So `a.b` is call [[get]] on deref(a) with toStringOrSymbol(deref(b)). and ~~a::b is call Symbol.bindGet on deref(a) with the value of deref(b)~~. [10:50:08.0979] Yeah, the metaprogramming aspect is incidental here, it's just required to get it to work since we have an *intrinsic* notion of an object being callable, but "invokable as a getter" is extrinsic in today's JS (based on how a function is attached to an object). [10:57:58.0189] I think I kept getting it the wrong way around as I was thinking of `a::b()` as a temporary method on a. So kept jumping to `a::b` being a temporary property of a. It’s been one of those Mondays [10:58:12.0676] * I think I kept getting it the wrong way around as I was thinking of `a::b()` as a temporary method on a. So kept jumping to `a::b` being a temporary property of a. It’s been one of those Mondays [10:58:35.0700] Wait, isn't `a::b()` a temporary method on `a`? [10:58:40.0424] it's not an unreasonable way to think about it, so that's understandable [10:58:54.0834] "temporary" = "not actually there" [10:59:24.0073] it's "a temporary method" *semantically*. Technically it's "unforgably call `b.call(a, ...)`", which has nothing to do with methods. [12:34:29.0786] Aha, I see, so it came from here. 😄 [12:35:42.0371] I do like Ron’s idea in https://github.com/js-choi/proposal-bind-this/issues/17#issuecomment-946055779. [12:55:18.0051] You can already do that with a Proxy, right? [12:56:07.0793] No one uses Proxies for this because they are almost a slow path, but that would be just as a much a problem for this, I would think [12:56:53.0024] I guess you can't actually do this with a proxy because the key is ToPropertyKey'd before it hits the proxy, never mind [13:30:14.0149] without extracting it, you can't explicitly call a getter in JS right now at all, and that's not the problem `::` is trying to solve [13:30:40.0948] the engine will call the getter for you, but you're not using invocation parens or `new` to do it [14:05:22.0281] Proxies do the *other* direction, where `ab` is controlled by `a` and lets them do something arbitrary based on `b`. The thing I and Ron are talking about is the reverse, where the `` is controlled by `b` and can do something arbitrary based on `a`. [14:06:15.0627] (I already answered this in the issue, but I'm not talking about extracting or calling getters *at all*, so I'm not sure why ljharb is bringing it up again here.) [14:07:16.0713] because i'm still not sure why getters are being brought up at all in relation to this proposal [14:07:23.0373] aka, Proxies let you do a *Map* where `map[key]` works and turns into `map.get(key)`. What I and Ron are talking about is having a *WeakMap* where `obj::wm` or `obj[wm]` turns into `wm.get(obj)` [14:07:37.0174] the proposal is about syntactic call or bind, which requires there be an actual receiver-sensitive function present in scope first. whether that function came from a data property or a getter is irrelevant. [14:08:43.0001] * the proposal is about syntactic call or bind, which requires there be an actual receiver-sensitive function present in scope first. whether that function came from a data property or a getter is irrelevant. [14:11:16.0261] I can try to explain it again? `a.b()` is a method call; `a::b()` is a faked method call, where `b` is an arbitrary function; it desugars to `b.call(a)`. Similarly, `a.b` is property access, but can also be getter/setter invocation if `a.b` is set up appropriately; my proposal is making `a::b` possibly to be a faked getter/setter, where `b` is an arbitrary object advertising some get/set behavior (likely thru a Symbol property); it desugars to `b[Symbol.bindGet](a)` [14:11:33.0034] right but that's still what i don't understand [14:11:40.0966] it's not actually a faked method call [14:11:43.0759] it's sugar for `.call` [14:11:48.0861] which requires a reified function [14:12:36.0629] and i also don't understand how the symbol protocol would play in, nor what actual use case motivates it [14:12:48.0547] Yes, under the covers it's `.call` sugar. But in *practice* it's a fake method call. That's the whole purpose of doing things like `const map = Array.prototype.map; foo::map(...)`; it lets you *pretend* that an arbitrary `foo` object has a `map()` method, without actually having to install a property on the `foo` object at all. [14:13:11.0849] sure, ok - and getters are methods too. you can do the same thing by extracting the getter and using .call or `::` [14:13:41.0065] adding a new symbol protocol is a lot of overhead, and encouraging/endorsing use of getters and setters is an ideological position i'm not understanding why we'd want to take [14:14:29.0409] "getters are methods too" yeah and they're invoked by `a.b`. So just like `a::b()` is a way to fake `a.b()`, `a::b` as a way to fake `a.b` (the getter/setter) is what I"m talking about. [14:14:30.0277] it would also mean that `::` couldn't be transpiled into an actually robust check, because it'd have to do a runtime lookup for the presence of the protocol (altho to be fair transpiling it would still require a robust callBind abstraction) [14:14:57.0017] * it would also mean that `::` couldn't be transpiled into an actually robust check, because it'd have to do a runtime lookup for the presence of the protocol (altho to be fair transpiling it would still require a robust callBind abstraction) [14:15:35.0075] so `a::b` and `a::c` would, depending on whether `a` had the Symbol method, invoke the same Symbol method with 'b' or 'c' depending? [14:15:46.0536] No, that's exactly the opposite. >_< [14:16:46.0876] The whole point of `a::b()` is that you can pretend `b` is a method of `a` *without `a` having to know anything about it*. This is the same - in `a::b`, it's the *`b`* that advertises it has get/set functionality, allowing you to use it on any object `a` without `a` having to know about it. [14:17:12.0984] (I've explained this both here and in the issue, and wrote a short code example showing it off.) [14:17:28.0143] i'm sorry that none of those explanations have made it clear to me, thanks for bearing with me [14:17:44.0239] ok so i have to have a `b` in scope, that has this symbol method defined on it, and then instead of doing `b.bind(a)` it calls the symbol method? [14:18:39.0885] Yeah. (This is obviously in conflict with using `a::b` as an unforgeable `b.bind(a)`.) This lets you use arbitrary "keys" or "properties" on an object without the object having to know how to deal with them. [14:19:00.0453] My first example was using a weakmap as an ephemeron key, but Ron's example of a Slice object applying to array-likes works just as well. [14:19:03.0786] ok so i think i understand the mechanics. but i definitely don't a) want to lose the critically important bind semantics, and b) i don't see any value in making anything about getters more ergonomic [14:19:35.0061] and while this shouldn't have much weight in language design, this would add a TON of weight to the transpiler emit for any usage of `::`, which would heavily discourage its use for many years [14:20:12.0671] The only complexity would be usage of `a::b` - `a::b()` would transpile to a `.call()` same as now. [14:20:15.0955] the point of getters is to be able to pretend something's a normal data property - and to *hide* the function call [14:20:30.0023] (Again, I recognize that this is in complete conflict with the other meaning of `a::b`.) [14:21:05.0052] tbh i think i'd rather lose the entire proposal than have this kind of getter-encouraging conceptual complexity [14:21:20.0856] but i'll think more about it, since that is a strong stance [14:22:06.0567] I don't understand what's any more conceptually complex than the current `a::b()`, but okay. [14:23:03.0016] `a::b` makes a function, and `a::b()` calls it. just like any other thing that you can call by sticking `()` on the end of. that `.` can invisibly call a function and looks like it won't is a huge wart on the language and i would not want to see it expanded. [14:24:56.0509] (i'd be fine seeing a more ergonomic way to extract getter/setter functions, as a separate proposal; the part i'm repulsed by is adding more invoking-paren-less invocation sites) [14:27:49.0986] I'm still not in any way talking about extracting getters/setters. No part of my proposal is connected to that concept in any capacity. [14:28:46.0138] i understand that. i'm saying that i think extracting getters/setters would be a better solution to the use cases you've presented. [14:29:00.0958] It... woudln't be? It wouldn't solve what I'm talking about at all. [14:29:17.0947] There is no way in which ephemeron keys can be addressed by extracting getters/setters from anything. [14:38:14.0648] To be a bit clearer, perhaps, you might recall that when we were first talking about private variables, having the syntax just be sugar for using weakmaps was a serious proposal. [14:39:12.0798] Like, using a Symbol, you can attach arbitrary data to an object in a guaranteed-collision-free manner. But it's not *private* - the object, or anyone who obtains the object, can find your Symbol and get at the data, and potentially get the same data from other objects you've used the Symbol on. [14:40:01.0549] A WeakMap allows the same functionality - associating data to an object without collisions - but does in a private manner. Nobody with the object can tell the data is there unless they *also* have your weakmap. [14:41:55.0707] The problem with using WeakMaps in this way is the ergonomics are worse than using properties - rather than `obj[privateKey]`, you have to write `privateKey.get(obj)`. And since it's method calls rather than syntax, you can' use assignment directly on it; the equivalent to `obj[symbol1][symbol2] = 3` is the horrible `weakMap2.set(weakMap1.get(obj), 3)`. [14:42:51.0227] So the thought was that we could use make some automatic weakmaps and have `foo.#bar` automatically be sugar for `bar.get(foo)`, where `bar` is a WeakMap the language automatically creates for you and which is syntactically available only in the class body. [14:43:58.0139] We ended up doing private state differently, but the use-case for WeakMaps doing this is still there, for things like membranes, or just generally any object-capability system. That's what I'm talking about. It's not the *sole* use-case for this syntax, but it's a pretty obvious one that's been discussed here in TC39 many times in the past. [14:45:57.0089] So `obj::weakmap1::weakmap2 = 3` would be able to desugar into the above automatically, allowing arbitrary objects to *pretend* to be getters/setters without the context object knowing about them, just like how `a::b()` lets b pretend to be a method without the context object knowing about it. [14:59:07.0586] * So the thought was that we could use make some automatic weakmaps and have `foo.#bar` automatically be sugar for `bar.get(foo)` (or `bar.set(foo, x)`), where `bar` is a WeakMap the language automatically creates for you and which is syntactically available only in the class body. [15:07:45.0166] Am I reading this right that Monrovia actually created a timezone that is 30 seconds off from the rest of the world? https://ptomato.name/talks/tc39-2021-10/#6 [15:08:28.0719] that used to be much more common; Monrovia was the only one that persisted past 1970 [15:08:51.0590] Cursed knowledge [15:09:06.0811] oh my lord https://www.timezoneconverter.com/cgi-bin/zoneinfo?tz=Africa/Monrovia [15:09:28.0499] their most recent DST transition was setting the clocks forward 44min30sec [15:09:58.0287] "most recent" being in 1972 [15:10:12.0157] Wikipedia says they stopped this in 1972 and moved to GMT? [15:10:22.0918] it's kind of a misnomer that that site calls that a DST transition; it's just a time zone change, they don't have DST there [15:10:24.0265] Thus the example in the slides being 1972, I see [15:10:31.0876] right [15:10:54.0815] yeah, i'm assumign this site just treats all time-zone changes as being DST transitions, since that is the 99% case for changing time zones [15:12:52.0106] Seems kinda sad to lose that information in the serialization, but if the IETF insists, whatevs... [15:16:02.0561] I agree. if I understood correctly, the insistence was not so much 'you cannot standardize this precision', but more like 'this would detract from the calendar annotation and would be better in a follow up' [15:17:01.0430] ryzokuken would be able to give more info 2021-10-19 [22:52:28.0241] ptomato: yes, exactly. [22:53:08.0990] Convincing people to make any changes to the existing grammar of 3339 is a very hard sell, and I wanted to prioritize getting the extensions standardized 2021-10-21 [10:16:20.0284] Is there a formal policy regarding the approval of normative changes to proposals in stage 3? [10:26:31.0934] I can't find one in ECMA262's contribution guide, the process document, or the "how we work" repository [15:22:29.0283] i don't think there is one; but if normative changes don't receive consensus before stage 4, then it'd presumably be required to achieve stage 4 - but at that point they may have already shipped. it seems reasonable to enhance the process document to indicate that within stage 3, normative changes require committee consensus? [15:27:17.0827] Yeah, that sounds right to me. I can file a pull request and go from there (the process document has a good place to mention this, too) [15:54:21.0915] Arg, rather, "the 'how we work' document has a good place to mention this, too" [16:09:34.0338] If "how we work" is being updated, one good thing to include would be how the proposal-advancement submission deadline affects normative changes for proposals *not* looking to advance, esp. during Stage 3 where implementers are actively finding bugs and bringing up issues. Concrete example: we discovered a Temporal spec bug several days after the deadline. Should we included it in our "Stage 3 update" slides next week? [16:12:30.0336] i feel like how it works in practice is add whatever you want with an hourglass emoji to make it clear it's a late addition [16:12:46.0649] leave it to chairs to deprioritize as needed [16:13:36.0623] if you're asking about discovering new info after an agenda item has already been added and whether that new info can be folded into the existing agenda item, that sounds straightforwardly fine to me [16:17:58.0009] https://github.com/tc39/process-document/pull/32 2021-10-22 [19:58:18.0638] Commented on the issue; the deadline only applies to stage advancement, not to non-advancement normative items [19:59:01.0491] you can add a non-advancement item the day of if you want (but it’d be reasonable for someone to withhold consensus out of a desire to spend more time thinking about it) [11:33:31.0076] ljharb: I won't be present at next week's meeting [11:34:12.0750] if I’m not too exhausted I’m happy to present it, otherwise we can wait til the next meeting after it [11:34:39.0677] Thanks! [13:04:32.0624] shu: https://github.com/tc39/proposal-resizablearraybuffer/pull/78 2021-10-25 [01:44:43.0660] jugglinmike: good catch, thank you [07:42:23.0351] what's the process for a person/company to become a delegate? i have a friend very interested in becoming a delegate, but neither he nor his employer are currently involved/delegates/members/etc 😅 [07:48:28.0749] ^ relevant to my interest as well! [07:50:28.0790] > <@dcrousso:matrix.org> what's the process for a person/company to become a delegate? i have a friend very interested in becoming a delegate, but neither he nor his employer are currently involved/delegates/members/etc 😅 There’s information at https://github.com/tc39/how-we-work/blob/master/join-tc39.md. [07:50:37.0288] Basically, it’s $75/yr for company-unaffiliated individual members. https://www.ecma-international.org/about-ecma/join-ecma/ [07:50:41.0350] does the employer want to become a member of ECMA? if not then the invited expert process seems plausible [07:50:42.0629] * Basically, it’s $75/yr for company-unaffiliated individual members. https://www.ecma-international.org/about-ecma/join-ecma/ [07:52:22.0724] Ah, yeah, there are also invited experts, which does not cost money. For example, there’s at least one Babel member who is an invited expert. Information about this is at https://github.com/tc39/how-we-work/blob/master/invited-expert.md. [07:52:40.0625] i dunno if his employer wants to join or not [07:52:40.0651] * Ah, yeah, there are also invited experts, which does not cost money. Information at https://github.com/tc39/how-we-work/blob/master/invited-expert.md. [07:53:02.0917] is it possible for him to join as an individual? either as an invited expert or some other thing? [07:53:17.0020] * Ah, yeah, there are also invited experts, which does not cost money. For example, there’s at least one Babel members who is an invited expert. Information about this is at https://github.com/tc39/how-we-work/blob/master/invited-expert.md. [07:53:26.0921] * Ah, yeah, there are also invited experts, which does not cost money. For example, there’s at least one Babel member who is an invited expert. Information about this is at https://github.com/tc39/how-we-work/blob/master/invited-expert.md. [07:53:58.0946] > <@jschoi:matrix.org> Basically, it’s $75/yr for company-unaffiliated individual members. https://www.ecma-international.org/about-ecma/join-ecma/ wait, where is this a thing? [07:54:26.0627] i don't see anything on that page that mentions an individual membership and was unaware that was an option [07:54:59.0172] Devin Rousso: unless something's changed, the path to be a delegate is pretty much for their employer to join. they can be an invited expert but typically that's usually for specific feedback on a specific topic or proposal [07:55:22.0604] they can also participate in the OpenJS Foundation's Standards Working Group, and then become a delegate for the foundation [07:55:41.0450] but if they're representing their employer in any way then the expectation is that their employer will join [07:58:59.0901] dope ty 😁 [07:59:01.0759] will relay [07:59:39.0772] > <@ljharb:matrix.org> i don't see anything on that page that mentions an individual membership and was unaware that was an option I was mistaken! I had misread the page. My apologies for misleading you, Devin. : ( [08:01:10.0907] > <@ljharb:matrix.org> i don't see anything on that page that mentions an individual membership and was unaware that was an option * I was mistaken! I had misread the page. My apologies for misleading you, Devin Rousso. : ( 2021-10-26 [07:28:47.0748] Michael Ficarra: "test262-parser-tests has a "fail" directory which is spiritually the same": No, "fail" there doesn't mean "it's okay for your implementation to fail this test", it means "your implementation should raise a SyntaxError because this test doesn't conform to the ES grammar". [07:29:46.0910] (test262-parser-tests' use of "pass" and "fail" as categories of tests is annoying: makes it difficult to talk about passing or failing a test.) [07:31:10.0455] jmdyck: but you could have a syntax extension [07:31:29.0263] yeah, that's why i said "should" rather than "must" [07:36:45.0086] jmdyck: that's the point, it's similar to the proposed test262 assertions on non-existence of extensions to built-ins [07:37:26.0963] ah, okay. [07:38:01.0334] but then I imagine that's true of the "early" tests as well [07:38:32.0207] is an implementation allowed to ignore an early error? I don't think so [07:38:53.0465] if so, though, then yes that is also analagous [07:40:26.0246] If you can ignore the grammar, then why not ignore an early error? But it's true the spec isn't very clear. [07:46:13.0335] But e.g. "Forbidden Extensions" says "When processing strict mode code, an implementation must not relax the early error rules of 12.8.3.1." which suggests that it *is* okay to relax other early error rules. [15:30:42.0053] jmdyck: we might want to work on clarifying the answer to that, editorially [15:30:54.0013] at least, once we know for sure what committee intent is [16:19:21.0767] Aye, there's the rub. [16:20:53.0044] https://github.com/tc39/ecma262/issues/2432 gets into roughly that area. [16:32:16.0639] https://github.com/tc39/ecma262/issues/1323 is another take. 2021-10-27 [06:39:59.0933] How would I construct a Map from a Spec List without any observable behaviors? [06:40:48.0778] https://tc39.es/ecma262/#sec-add-entries-from-iterable [06:41:22.0021] hm, actually that's a lot of hoops [06:41:34.0397] I would have to convert my `List>` into `Array<[key, value]>`, first [06:41:50.0589] see steps 3-7 in https://tc39.es/ecma262/#sec-map.prototype.set [06:41:53.0165] Can I just construct a object with `[[MapData]]`? [06:42:00.0717] iow, iterate over the list, and just mutate the Map entries of the Map you created [06:43:13.0386] 👍️ [06:44:02.0013] > Can I just construct a object with `[[MapData]]`? You can but for clarity I would call `%Map%` and then mutate its internal slots [06:44:17.0764] I like having `Map` be the sole thing which creates an object with a `[[MapData]]` [06:44:46.0615] Thanks [06:47:18.0004] That's pretty much what structured deserializing does for Map objects, although we don't construct the objects properly; I guess shu gets to fix that 😛 [06:47:45.0189] maybe an AO is in order that HTML and grouping can use [06:49:59.0846] CreateMapFromList, why not [06:59:32.0418] > <@annevk:mozilla.org> That's pretty much what structured deserializing does for Map objects, although we don't construct the objects properly; I guess shu gets to fix that 😛 Do you have a link? [06:59:47.0971] Curious what data structure you have, so I can put together a helper abstract op [07:02:02.0054] Justin Ridgewell: https://html.spec.whatwg.org/#structureddeserialize then search for [[MapData]] [07:02:35.0028] Justin Ridgewell: there's a plan of sorts to move a lot of that into ECMAScript aiui, shu would know more [07:03:21.0906] Justin Ridgewell: see domenic's comment at the bottom of https://github.com/tc39/ecma262/issues/2555 [07:03:44.0026] mostly some mechanical shoring up of the language in HTML around object creation. i haven't looked too deep but can't imagine its being very problematic [07:06:45.0949] Looks like you already have a `{ [[Key]]: key, [[Value]]: Value }` record, and you're just ferrying things through the realms [07:07:41.0458] I can modify my ops to match that pretty easily, then call a `CreateMapFromList` with `List<{ [[Key]], [[Value]] }>` 2021-10-28 [19:36:31.0182] It would be great if somebody could take a look at https://github.com/mdn/content/pull/9940 and comment [19:37:29.0428] that seems to be only in a Stage 2 proposal, which would generally make it not appropriate for documenting at MDN yet [20:52:44.0120] > Seems to be only in a stage two proposal Correct [20:52:51.0512] * > Seems to be only in a stage two proposal Correct 2021-10-29 [15:48:21.0310] I’m not sure why, but ecmarkup 9.4.1 complains when I give this grammar for a syntax-directed operation: ``` MultiplicativeExpression : MultiplicativeExpression MultiplicativeOperator ExponentiationExpression ``` [15:48:44.0857] It says: ``` warning: could not find definition corresponding to production MultiplicativeExpression (grammar-shape) at spec.html:138:7: > 138 | MultiplicativeExpression : MultiplicativeExpression MultiplicativeOperator ExponentiationExpression | ^ ``` [15:58:00.0600] As far as I can tell, it should match MultiplicativeExpression’s production… 2021-10-30 [17:05:23.0982] jschoi: in a proposal, or in the spec? [17:07:07.0616] must be a proposal, if there's an on line 138 [17:07:14.0794] fair point [17:10:41.0541] jschoi: that warning is designed for the full spec, where the full grammar is available; I guess I did not properly disable it in proposals. so the problem is that ecmarkup does not know about that production because the proposal doesn't define it. I'll fix the suppression at some point; in the mean time, just ignore the warning, it'll still build [17:12:27.0456] So there isn't a way for a proposal doc to include/import definitions from the spec? [17:13:34.0559] Short of copy-pasting, no [17:13:53.0070] at some point I mean to put that sort of thing into the biblio and also make the bilio updatable, but I haven't done so yet [17:13:55.0563] But there's a 'biblio' file? what does that do? [17:15:03.0892] * So what's in the biblio file currently? [17:15:06.0251] It's basically a list of all AOs, which is used to generate the automatic xrefs in proposals [17:15:44.0125] (AOs and their #ids, I should say, as well as a couple other things.) [17:15:59.0508] ok thanks [17:17:02.0591] but it hasn't been updated since ES6, which is no good; see https://github.com/tc39/ecmarkup/issues/251 also there's a bunch more information we could usefully include now; see https://github.com/tc39/ecmarkup/issues/316 [17:19:59.0016] (it does actually have a list of productions currently, but not what's actually _in_ the productions, which is the thing this rule needs) [19:25:41.0208] bakkot: Thanks for explaining. [21:56:44.0556] * bakkot: Thanks for explaining. Ah, I also see https://github.com/tc39/ecmarkup/issues/366 now, great. [21:56:55.0801] * bakkot: Thanks for explaining. Ah, I also see https://github.com/tc39/ecmarkup/issues/366 now; great.