2020-06-01 [08:41:27.0000] Hi? [08:42:12.0000] ryzokuken o/ [08:42:21.0000] hi Bakkot [08:42:24.0000] def a netsplit [08:42:40.0000] I wasn't disconnected, but seems like a bunch of people were. [12:32:40.0000] JS already has `return` from expression position... in generators, `yield` can do it [12:33:30.0000] jorendorff: you should join #tc39-delegates [12:33:50.0000] thanks! [13:13:24.0000] ljharb: good discussion today, thanks for participating. I have a few follow-up questions, if you have any time to chat more today [13:14:14.0000] maybe i should just ask in the github issue [13:32:17.0000] jorendorff: sure, any time 2020-06-03 [06:56:28.0000] its not possible to export * from something and then replace one of those exports with your own is it [06:56:59.0000] like `export * from 'fs'; export function readFile() {}` [07:09:24.0000] devsnek: sure you can [07:10:59.0000] https://tc39.es/ecma262/#sec-getexportednames step 9.c.i.1 [07:12:32.0000] oh interesting [07:12:46.0000] i thought all collisions were errors [07:17:38.0000] /me laughs nervously at ever thinking i've learned all of `export *` [07:18:44.0000] this came up in our APM example loader we did a few years ago (... this ESM stuff has taken too long) [07:47:21.0000] i still wish we had been able to add `default` back to `export *` [07:47:37.0000] just couldn't get consensus [08:24:28.0000] Maybe time for `export default from ''`? [08:26:14.0000] jridgewell: that won't help [08:26:24.0000] jridgewell: cause you still need to know that '' has a default [08:26:28.0000] `export { default } from ''` already works [08:27:23.0000] jridgewell: https://github.com/tc39/proposal-export-default-from [08:27:43.0000] I think that requires people to understand that `default` is just a named export [08:27:54.0000] It's easier for me to think about it as separate [08:28:29.0000] Especially because it's teated separately in `export * from ''` [08:29:13.0000] i'd like that proposal to go forward, fwiw. default is special, it's not *just* a named export - it's just unfortunately implemented as one [08:32:56.0000] i don't think it should be considered special [08:33:18.0000] cause if you named an export "default" it would be really weird if it was a different thing [08:35:14.0000] it's conceptually special, regardless of what's observable [08:40:08.0000] special because of the a syntax or something else? [08:42:40.0000] i usually describe it to folks as: a default export is what a module *is*, a named export is something a module *has* [08:44:47.0000] I've always looked at it like the difference between `module.exports = …` vs `exports.foo = …` [08:44:49.0000] i think thats a hard thing to think personally [08:45:11.0000] jridgewell: well you can kinda see how the `default` gets really gross if you think of it that way [08:45:32.0000] at least in node's issue tracker trying to do things like make __esModule interop work [08:45:47.0000] In commonjs, yes it will. In our system, we don't have to mutate default to get similar behavior [08:46:12.0000] can you clarify that [08:47:56.0000] /me Sorry, I thought you were talking about mutating the `module.exports = function foo() {}` [08:48:01.0000] bradleymeck: CJS only has a default export. [08:48:09.0000] ^ that wasn't supposed to be a `/me`... [08:48:17.0000] ljharb we have argued about that before [08:48:17.0000] `exports.foo` is people trying to shoehorn named exports into a module system without them. [08:48:33.0000] Then doing a `foo.bar = other`, so that you can `const { bar } = require('')` [08:48:44.0000] ljharb CJS has a different notion of exports than ES modules; I don't think "CJS only has a default export" is really a meaningful claim [08:49:03.0000] "default export" is a concept which makes sense in the context of ES modules, not CJS modules [08:49:05.0000] i mean, CJS only exports a single value [08:49:10.0000] but sure, fair [08:49:24.0000] yeah, that claim I can agree with [08:49:49.0000] (also the concept of default exports in ESM was added for the purposes of matching CJS, iirc) [08:50:14.0000] yeah, that was the original sin [08:50:22.0000] that is certainly one take [10:59:16.0000] bradleymeck: what would you think about `export get function whatever() {}` [10:59:20.0000] so you could wrap live bindings [10:59:33.0000] ew [10:59:40.0000] we talked about it previously [11:00:32.0000] i have no strong feelings but replacing it gets weird, would it always call that identifier if accessed or would that be a "non-configurable" export? [11:00:39.0000] right now fn decls can be replaced [11:00:53.0000] that would expose a new ability tho [11:01:07.0000] currently you can't replace a live binding as a *response* to someone importing it [11:01:35.0000] iow with a getter it seems like you'd be able to count imports [11:02:06.0000] not imports, accesses [11:02:31.0000] ah ok so `import { whatever }` wouldn't trigger it, but referencing `whatever` would [11:02:36.0000] ok so then that seems even worse :-) [11:02:46.0000] you can't do that on variables now [11:02:47.0000] i think any useful abstraction here, not just `export get`, would have that [11:03:29.0000] or you would have to be aware of changes within the module you're wrapping [11:03:39.0000] Object.observe lol [11:09:59.0000] yeah that's terrible [11:10:09.0000] local references should not cause side effects [11:10:11.0000] strongly affirmed [11:11:15.0000] those reasons are also applyable for falsy evaluation of document.all. 1. it's increasing engine maintaining cost; 2. security problems happened for this behavior [11:11:48.0000] IMO if we can remove this big feature from the language, we should also remove document.all == false [11:12:32.0000] jackworks: i think to change anything about document.all you'd have to prove it was web compatible to do so [11:12:46.0000] it's even smaller and won't break much sites as restring subclass ability [11:13:42.0000] yeah, we can collect a list of classic sites that using document.all == false and no longer maintaining, then only let document.all == false on those sites [11:14:05.0000] jackworks: browsers have refused to do that in the past [11:14:23.0000] but you could certainly ask :-) [11:14:38.0000] is there a good reason for that? 🤔 [11:16:10.0000] I have to say I think [[IsHTMLDDA]] is poisoning the spec text [11:16:18.0000] priority of constituencies [11:16:42.0000] (https://www.w3.org/TR/html-design-principles/#priority-of-constituencies) [11:16:45.0000] ^ that. the spec text can be as ugly as it needs to be to ensure things work properly for users [11:17:05.0000] we couldn't get rid of it but we *could* give it a passive-aggressive name :p [11:17:17.0000] hence IsHTMLDDA [11:17:42.0000] MISTAKESWEREMADEDDA [11:17:45.0000] can leave this [[IsHTMLDDA]] extension in the HTML spec since only HTML is using it. and only exact 1 object has this internal slot [11:18:05.0000] jackworks: the reason it was added to the JS spec is to remove the willful violation from HTML [11:18:16.0000] yeah it used to be in the html spec [11:18:17.0000] jackworks: we can't remove the slot from JS without HTML having to restore the willful violation in equality semantics [11:19:41.0000] > you'd have to prove it was web compatible to do so; Yes, it should be proved to be safe, but how? I can't access telemetry data from Chrome or Firefox afterall. [11:20:02.0000] you'd have to make the case to one or more browsers to ship counters [11:21:23.0000] [[IsHTML_document.all]] lol [11:21:33.0000] that's what we have already yes [11:24:03.0000] jackworks yeah there is zero chance removing document.all would be web-compat [11:24:18.0000] and shipping the list of sites where it would work would bloat browsers by at least megabytes, probably more [11:24:50.0000] jackworks you could ask Chrome or Firefox to explore it [11:25:51.0000] > there is zero chance removing ... would be web-compat \n yes, and this argument also works for the builtin subclass restriction [11:26:26.0000] jackworks: except there's tons of sites that use document.all from the olden days [11:26:37.0000] jackworks I don't think that's actually true [11:26:40.0000] there's unlikely to be many, or even any, that have shipped subclassing in the last 5 years [11:26:41.0000] it is an emperical question [11:26:54.0000] you can make a custom build of a browser that does not have built-in subclassing, and see what breaks, and do the same for document.all [11:27:01.0000] (less than 5; `class` hasn't been web compatible for all 5 years) [11:27:03.0000] and it is my strong belief that far more websites will beak in the latter case [11:27:16.0000] don't break the space jam movie website [11:29:06.0000] jackworks: we are actively crawling the sites like those in https://www.chromestatus.com/metrics/feature/timeline/popularity and via http-archive audits to trap any actual usage of species [11:29:46.0000] and removing it doesn't actually break things / things are using @@species in ways that break the actual usage of it [11:29:54.0000] `class` hasn't been web compatible for all 5 years \n This can convince me, thanks @ljharb , but I'm still feeling not good in the inconsistency of treating delete IsHTMLDDA or subclassing builtins [11:29:59.0000] so thats why it doesn't appear to be so breaking [11:30:19.0000] we can't remove every terrible thing, alas [11:30:28.0000] but if we investigate and discover we can, great [11:31:04.0000] document.all is something like 20% of all sites https://www.chromestatus.com/metrics/feature/timeline/popularity/83 vs Array[@@species] which is at 0.006% [11:31:40.0000] that's surprising me, why over 25% sites are using document.all? [11:31:46.0000] who knows [11:32:16.0000] i'd bet more than 25% of all sites have barely been touched in 20 years [11:32:32.0000] is it hiding in a popular library like mootools 🤔 [11:32:45.0000] i'm sure it's hiding in old versions of many popular libraries [11:32:56.0000] i used it in the mid-2000s as part of browser detection code [11:33:32.0000] ljharb: yea but even then if they are accessed this year does it matter? [11:33:48.0000] my passive aggression comment wasn't completely a joke btw [11:34:08.0000] bradleymeck: yes [11:34:17.0000] if we wanted to *justify* the thing's existence we'd've called it MasqueradesAsUndefined or something [11:35:36.0000] curious, I thought most of the users are accessing modern sites like youtube twitter etc so the usage won't be too high [11:37:26.0000] jackworks: iirc it's not about usage, it's about sites [11:37:38.0000] or maybe both, i'm not sure how browsers analyze the data [11:41:04.0000] chrome web stats is page loads [11:41:09.0000] so more popular ones are counted more heavily [11:42:08.0000] ah ok, gtk [11:43:42.0000] > if we investigate and discover we can, great \n that make sense 🎉 2020-06-04 [06:37:01.0000] Is the Realms proposal update being to presented at first today? The agenda says so but I want to make sure 😆 [06:41:30.0000] jackworks: yes [07:40:08.0000] For those of you interested in equality of Records and Tuples, here's a PR that moves to "SameValueZero" semantics for == and ===, reviews appreciated https://github.com/tc39/proposal-record-tuple/pull/130 [07:41:54.0000] And, for those of you interested in module attributes caching and host invariants, here's a PR to restrict module attributes to only "check"-type attributes. The idea would be that this forms part of what we're proposing for Stage 2 later today, if it looks good to you all. https://github.com/tc39/proposal-module-attributes/pull/66 2020-06-09 [09:27:00.0000] strawman proposal: noawait sections in async functions that you can put around cache operations [09:28:18.0000] example https://gc.gy/59425087.png [09:29:05.0000] (only half joking) [09:50:49.0000] devsnek you could just wrap it in an IIFE [09:53:10.0000] Bakkot: but that doesn't add any new syntax [14:40:06.0000] devsnek: why no go the whole way and just set the grammar flags whole sale, `do with (-await) {}` [14:40:38.0000] bradleymeck: i'm on board as long as it uses tilde and uppercase Await [16:52:50.0000] ljharb: what is your definition of forgeable 2020-06-10 [17:01:25.0000] like thenability is forgeable, instanceof is forgeable, brand checks are not [17:04:17.0000] iow identity is indeed unforgeable for objects and symbols, but forgeability goes way beyond just identity to me [17:04:53.0000] webidl has a definition of "unforgeable", which applies to attributes: https://heycam.github.io/webidl/#dfn-unforgeable-on-an-interface [17:14:49.0000] ljharb: hm I guess it applies in a lot of situations [17:16:51.0000] in regard to values, it means you can't create a value with the same identity, you have to have the actual value to have the same identity [17:17:09.0000] which is the distinction we're using for weak collection keys [17:21:20.0000] devsnek except the current proposal allows `Symbol.for` symbols, I think [17:21:50.0000] those are still unforgeable [17:22:01.0000] not any more unforgeable than string literals, surely? [17:22:01.0000] symbol.for doesn't create new values, there's a cache [17:22:17.0000] I don't understand the distinction between Symbol.for symbols and strings [17:22:26.0000] what is the relevant distinction here? [17:22:41.0000] you can create caches of objects too [17:23:01.0000] ... so? [17:23:14.0000] I mean from some level of abstraction nothing is unforgeable because you can store it in something keyed by strings [17:23:22.0000] neither Symbol.for symbols nor strings are objects [17:23:38.0000] I don't see what the distinction between those two things is [17:24:12.0000] I get splitting out objects from non-Symbol.for symbols: there if you don't already have access to the thing, possibly transitively (via a cache or whatever), you cannot get it [17:24:32.0000] but this is not true for Symbol.for symbols or for strings [17:24:48.0000] those you can synthesize in a new realm without access to anything outside of the realm [17:25:33.0000] but the symbols in the agent cache aren't being forged, they're just normal symbols [17:25:46.0000] I don't know what you mean by forged [17:25:55.0000] the point of this conversation is to try to get at what you mean by forged [17:26:10.0000] a new value is created with the identity of some other value [17:26:36.0000] I don't know what it means to be a "new value" but have the identity of another value [17:26:50.0000] that seems like it is tautologically impossible [17:26:53.0000] like two strings both containing the same characters in the same order [17:27:55.0000] how is that any more of a new value than a Symbol.for symbol is? [17:28:18.0000] because symbol.for doesn't always return a new symbol [17:28:33.0000] neither does writing a string literal [17:28:50.0000] it definitely does [17:29:00.0000] maybe in your implementation, not in mine [17:29:06.0000] the difference is not observable to user code [17:29:44.0000] I'm not sure what optimization has to do with this [17:29:59.0000] you're the one who brought it up? [17:30:10.0000] no I didn't [17:30:52.0000] you said "symbol.for doesn't always return a new symbol". this is exactly as true as "writing a string literal doesn't always return a new string". [17:31:08.0000] no symbol.for is specified to not always return a new symbol [17:31:19.0000] string literals are not specified to return new values either [17:31:28.0000] the spec in fact speaks of "the" empty string [17:32:24.0000] I'm not sure what we're talking about anymore [17:32:59.0000] my point was being able to cache a type doesn't make it a forgeable type [17:33:13.0000] I'm trying to understand what distinction you see between Symbol.for symbols and string literals, from the perspective of, only the former is "forgeable" [17:33:25.0000] symbol.for symbols are symbols [17:33:33.0000] we only have one kind of symbol in js [17:34:04.0000] depending on what you mean by "kind", sure [17:34:13.0000] but this does not help me understand what you mean by "forgeable" [17:35:40.0000] all objects, and symbols not created by Symbol.for, have the property that code running in a fresh realm cannot get access to them. but this is not true of symbols created by Symbol.for, just as it is not true of string literals. so clearly this cannot be the definition of "forgeable". [17:35:45.0000] forgeable = you can create a value that has the identity of another value without having access to the original value [17:36:43.0000] ok, so, in what way are Symbol.for symbols not forgeable? [17:36:58.0000] you have to look up the original value using Symbol.for [17:37:02.0000] you can't produce it out of thin air [17:37:33.0000] Symbol.for is thin air [17:37:50.0000] it exists in fresh realms; it does not need to be passed in [17:37:57.0000] that's what i meant above [17:37:59.0000] "I mean from some level of abstraction nothing is unforgeable because you can store it in something keyed by strings" [17:39:12.0000] you can't store it in a way which will be available to code with which you share no communication channel [17:39:37.0000] i.e. you have to actually pass the value, or a thing which has access to the value, to the new code [17:39:41.0000] i.e. it can't make it itself [17:39:45.0000] this is not true of Symbol.for symbols [17:39:49.0000] for mark's definition of communication channel sure [17:41:59.0000] for any definition of communication channel [17:42:49.0000] sure [17:43:33.0000] i would just say the globals are passed to the realm and therefore the symbol is passed to the realm [17:47:30.0000] Bakkot: i think the crux of this is just that you cannot recreate the value with undeniable computation / primitive computation [17:49:46.0000] basically the idea is since you can censor `.for` using APIs but cannot censor things like 'it'+'erator' [00:02:23.0000] Hi all! [00:02:31.0000] I am having a little problem understanding why - AssignmentRestProperty doesn't allow Array or Object Literal inside it, but AssignmentRestElement allows them [00:02:44.0000] So, I can write `[a, ...{0: b, length: c}] = [1,2,3,4,5]` but not `({a, ...{b}} = {a: 1, b: 2})` [00:02:54.0000] What is the reason for allowing destructuring after ... in array destructuring, but not in object dest.? [00:04:08.0000] This is the relevant spec link - https://tc39.es/ecma262/#sec-destructuring-assignment-static-semantics-early-errors [00:04:14.0000] bendtherules: the former is gathering the first item in `a` and the rest in an array, that you're destructuring [00:04:41.0000] bendtherules: i can see why you'd think the latter is allowed, but it seems nonsensical to me since you can just remove the `...{ }` [00:05:30.0000] True, but then what is the rational behind allowing `[a, ...[b, c]] = []`? [00:06:13.0000] Array literals seem to allow both obj. and array dest, after ... [00:06:26.0000] i'm not really sure [00:06:37.0000] but `...{b}` is 100% redundant for `b` [00:06:56.0000] further destructuring the rest array in an array destructuring isn't always 1:1 [00:07:42.0000] not 1:1 as in? [00:08:14.0000] It will still take values out of the iterator in the same way, right? [00:08:47.0000] yeah, i suppose the nested array destructuring inside rest doesn't make much sense [00:09:02.0000] ie `[a, ...[b, ...c]] =` is the same as `[a, b, ...c]` [00:09:08.0000] I can only think of one thing. correct me if i am wrong [00:09:27.0000] the second one will still take out all values of all the iterator [00:09:36.0000] *value out of the iterator [00:09:42.0000] so will the first one [00:10:18.0000] i mean `[a, b]` vs `[a, ...[b]]` [00:10:44.0000] Yes, in your example it will be the same thing [00:14:55.0000] About `...{b}` being same as `b` - Is it exactly the same thing (if it was allowed)? [00:15:31.0000] `...{b}` would still GET all the remaining enumerable properties, right? [00:15:42.0000] Can that have a side effect? [00:18:34.0000] yes, i suppose that could [00:21:42.0000] Was this willingly left out for some reason? [00:21:42.0000] Looking through the early errors, i see that AssignmentRestProperty is restricted, but AssignmentRestElement is not [00:26:24.0000] Also about the `[a, ...{length: b}]` case - what are the usecases? [00:27:04.0000] Because the ... part is always a new array, it will have just numeric indexes and length property. What i can think of - get a random index value, or get length of remaining elements. [00:27:20.0000] i don't honestly know the history [00:27:29.0000] your thinking seems reasonable to me tho [00:28:27.0000] got it. Last question - can i somehow track the discussions of this proposal (because it is already merged, i suppose)? [00:29:50.0000] destructuring was in ES2015, so it's long since shipped, and never went through the current proposal process. [00:30:00.0000] any discussions would be in the notes, not likely on github [00:34:15.0000] 👍 Makes sense. Thanks for the help @ljharb. [08:49:54.0000] ljharb / bendtherules: object rest/spread was not in ES2015 and was a "modern" proposal [08:50:00.0000] its repo is at https://github.com/tc39/proposal-object-rest-spread [09:15:31.0000] right sorry, object destructuring was but not rest, that was later [09:16:59.0000] I actually recall talking about this specific question at the time but I can't find it in the notes [09:48:54.0000] I just found this - https://github.com/tc39/notes/blob/015f9392787bd9cb86f172af3d55d0475e87db26/meetings/2017-05/may-23.md [09:49:22.0000] Which seems like when rest in obj dest. was decided to be not allowed [09:49:42.0000] aha, yes, that's the conversation I was thinking of [09:50:21.0000] @Bakkot: do you remember if there was similar discussion within array dest.? [09:50:31.0000] bendtherules: that's before my time, alas [09:50:49.0000] array rest/spread was in ES2015, so it was discussed earlier [09:51:13.0000] Ok, I'll try to search later [09:51:33.0000] https://github.com/tc39/notes/blob/8e8bfcbddcb29c09a10b0845a55af2e0d31b6f49/meetings/2015-07/july-28.md#66-bindingrestelement-should-allow-a-bindingpattern-ala-assignmentrestelement [09:52:27.0000] And @ljharb - seems like there is a diff between `{a, ...{b} } ` and the basic form - because it only takes from own props [10:24:32.0000] @Bakkot: hmm, so binding was made similar to assignment in array rest case. Wondering if the assignment case was decided on purpose or discussed earlier. [10:37:28.0000] Ok, so some more discussions are here - https://github.com/tc39/proposal-object-rest-spread/issues/43#issuecomment-307957597 [10:39:35.0000] In conclusion, it feels like there wasn't a strong case for obj destructuring within obj, but the array stuff was already there by that time. That wasn't removed as such. [11:33:13.0000] bendtherules: ah true 2020-06-18 [07:40:43.0000] The behavior of displaying class name of object in chrome console is weird : For `class Test {}` it will show `Test {}` even Test have `Symbol.toStringTag` defined. But for `class Test1 extends Test {}`, it will show `Foo {}` (assume `Test.prototype[Symbol.toStringTag]` is `"Foo"`). [09:39:31.0000] haxjs: in my chrome i see `class Test` and `class Test1` with `class Test { get [Symbol.toStringTag]() { return 'Foo'; } } class Test1 extends Test {} [Test, Test1]`, same for the instances [09:40:20.0000] haxjs: i'd only expect the toStringTag to show up with Object.prototype.toString, and indeed i see `new Test1() + ''` and `new Test() + ''` print `[object Foo]`. [09:40:31.0000] ljharb: this is another weird issue, getter have different behavior. [09:41:32.0000] On the other hand, Node.js have consistent and reasonable result. [09:41:54.0000] haxjs: `class Test {} Test.prototype[Symbol.toStringTag] = 'Foo'; class Test1 extends Test {} [Test, Test1]` gives me the same behavior in chrome's repl [09:42:19.0000] ah, i do see `new Test1()` in the second example print `Foo {}`, so that seems like a bug [09:42:54.0000] haxjs: specifically, if i then do `class Test {} Test.prototype[Symbol.toStringTag] = 'Foo'; class Test1 extends Test {} [Test, Test1]` it restores the proper behavior [09:43:10.0000] so the bug seems to be when Symbol.toStringTag is *enumerable* on a subclass, it incorrectly uses it [09:43:30.0000] (or, that it incorrectly ignores it when it's not enumerable, everywhere else, but that doesn't seem right to me) [09:44:38.0000] I guess it's a bug, but can't understand how this bug occur 😅 [09:44:38.0000] haxjs: want to file it? :-) [15:01:00.0000] should `Reflect` have a toStringTag? [15:01:05.0000] someone please have an opinion on this [15:06:44.0000] Bakkot: don't tempt me [15:16:20.0000] Bakkot: sure [15:18:13.0000] Bakkot: specifically, "sure" to the "let's retrofit all the namespace objects that don't have @@toStringTag with a @@toStringTag" [15:19:31.0000] though one day i would like to get out of the business of having opinions, that'd be nice [15:37:53.0000] Bakkot: yes, for debuggability 2020-06-19 [06:22:43.0000] if initializing import.meta could fail [06:23:10.0000] like say there's a compartment hook for it [06:23:34.0000] what is a reasonable behaviour for it failing [06:27:21.0000] devsnek: probably like how import() failing doesn't need to cache the error, just fire the host hook again and have it fail again [06:27:48.0000] seems scary [06:28:26.0000] its just a thrown error I would assume [06:28:33.0000] yeah [06:29:50.0000] i don't think it should get a value at least, and import.meta is always an object so, error [06:36:57.0000] yeah just the idea of it throwing multiple times feels weird [06:59:19.0000] devsnek: import() returns new rejected promises even if you cache the error [06:59:54.0000] you could always add a .then() to all your import.meta objects and await it ;-) [07:00:14.0000] .then is such a huge surface these days :-( [10:44:40.0000] Where can I find the proposal to reduce support for @@Species? [10:58:24.0000] jorendorff: https://github.com/syg/proposal-rm-builtin-subclassing [11:00:16.0000] thanks [11:11:47.0000] can a chair block this user? https://github.com/tc39/ecma262/pull/1376#issuecomment-646777580 [11:11:57.0000] appears to be automated spam on a few of our repos [11:12:16.0000] to me, anyway, unless someone else knows otherwise [11:54:37.0000] i reported them, maybe github will take care of it [16:49:40.0000] I have what may be a really stupid question, but here goes. Why does the lexical grammar even still exist in the spec? [16:53:16.0000] toddobryan: how do you mean "still"? I think this this summarizes the interacting grammars quite nicely: https://v8.dev/blog/understanding-ecmascript-part-3#ecmascript-grammars [16:53:46.0000] I've been implementing a parser and, the best I can tell, it's impossible to write a tokenizer. The spec talks about InputElementDiv, InputElementRegExp, InputElementRegexpOrTemplateTail, and InputElementTemplateTail as alternative goals for parsing, but none of them are referenced in later grammars, which use literal symbols extensively. [16:55:24.0000] The Whitespace production is only referred to in those rules, which, as mentioned, aren't reachable from any of the higher-level symbols like Program and Script. [16:59:02.0000] @rkirsling That's the thing. You'd expect the syntactic grammar to be written in terms of tokens, but it's not. It's written in terms of characters. [16:59:30.0000] where is it written in terms of characters 2020-06-20 [17:00:11.0000] maybe the `of` in a for/of statemenr [17:00:17.0000] Even though Punctuator is defined in the lexical grammar, it's not used in the syntactic grammar. Instead you have things like RelationalOperator or EqualityOperator. [17:00:41.0000] ah you mean when it does bold text [17:01:29.0000] generally those occurances are described by the lexical grammar, even when it doesn't specifically mention the lexical production in question [17:01:42.0000] Exactly. [17:02:24.0000] Really, they're not. Like I said, the lexical grammar includes Punctuator. Nowhere is that referred to in the syntactic grammar. [17:03:13.0000] toddobryan: if it helps, think of them like c enums [17:04:34.0000] everything used in the syntaric grammar should be well defined in the lexical grammar even it not directly referring to it [17:04:44.0000] syntactic* [17:05:32.0000] And I lied above. RelationalOperator and EqualityOperator don't exist. I created them when I was writing my grammar. In the lexical grammar, they're not distinguishable (all under Punctuator) and in the syntactic grammar, they're literals: https://www.ecma-international.org/ecma-262/#prod-RelationalExpression and https://www.ecma-international.org/ecma-262/#prod-EqualityExpression. [17:08:06.0000] toddobryan: I'm not sure I understand what the problem is 😅 [17:08:30.0000] devsnek: I'd be fine with that, but nowhere in the spec does it specify how/when you should choose between the goal symbols of InputElementDiv, InputElementRegExp, etc. [17:09:00.0000] it shouldn't ever have to specify how you choose [17:09:20.0000] there are maybe two places where it does (if statements and some regex thing in annex b) [17:09:34.0000] there's a pr open to fix the if statement one [17:09:39.0000] It does specify: "The InputElementRegExpOrTemplateTail goal is used in syntactic grammar contexts where a RegularExpressionLiteral, a TemplateMiddle, or a TemplateTail is permitted. The InputElementRegExp goal symbol is used in all syntactic grammar contexts where a RegularExpressionLiteral is permitted but neither a TemplateMiddle, nor a TemplateTail is permitted. The InputElementTemplateTail goal is used in all syntactic grammar [17:09:39.0000] contexts where a TemplateMiddle or a TemplateTail is permitted but a RegularExpressionLiteral is not permitted. In all other contexts, InputElementDiv is used as the lexical goal symbol." [17:09:54.0000] OK--here's the basic problem. If the left-hand side of a grammar production never appears in the right-hand sign of another rule, that production is unused and provides no information to the spec. [17:10:16.0000] Find me a place where InputElementDiv is used in the syntactic grammar. [17:12:22.0000] The information it provides is in how to divide up the source text. [17:13:10.0000] I think it's described in section 11? [17:14:44.0000] But it's not actually used. In the syntactic grammar, the input is referred to explicitly, not the productions that the lexical grammar provides. [17:16:47.0000] And since the syntactic grammar does not explicitly use those rules, it's almost impossible to write a tokenizer. (Or at least it has been for me.) [17:17:17.0000] The syntactic grammar is not defined over the source text. If it were it would have to deal with whitespace and comments. [17:18:08.0000] The point of splitting them is so that the lexical grammar can deal with whitespace and comments, including stuff like "is `/ a /` three tokens or one" [17:19:02.0000] to quote the page I linked [17:19:03.0000] > In implementations, the syntactic grammar analyzer (“parser”) may call the lexical grammar analyzer (“tokenizer” or “lexer”), passing the goal symbol as a parameter and asking for the next input element suitable for that goal symbol. [17:20:59.0000] OK. Fair enough. But how would I know when to use the `InputElementRegExp` production to get the next token? [17:21:20.0000] See note 1 here: https://www.ecma-international.org/ecma-262/#prod-GeneratorMethod [17:21:56.0000] There is no such note anywhere that references InputElementRegExp. (That I can find. I'd be happy to learn I'm missing something.) [17:22:34.0000] in terms of concrete implementation you don't usually see any specific "now we're lexing the input" type stuff [17:22:43.0000] aside from handling hashbang [17:23:05.0000] The bit I quoted above says you'd use `InputElementRegExp` to get the next input element "in all syntactic grammar contexts where a RegularExpressionLiteral is permitted but neither a TemplateMiddle, nor a TemplateTail is permitted" [17:24:00.0000] all the implementations I know of use a whitelist of allowed tokens preceding the yield [17:24:18.0000] there aren't that many [17:24:23.0000] *following? [17:24:29.0000] rather than preceding [17:24:32.0000] yeah that lol [17:26:17.0000] So, you'd use `InputElementRegExp` when applying `PrimaryExpression`? (I did a quick search, and I think that's the only rule that `RegularExpressionLiteral` appears on the right of.) [17:27:08.0000] mmm.... "when applying" doesn't exactly make sense, I think [17:27:37.0000] if you've just parsed _part_ of an expression, like `a +`, then you'd use InputElmentRegexp` [17:27:49.0000] When trying to satisfy? [17:28:43.0000] The spec is kind of written on the assumption that you'll be using a bottom-up parser, probably specifically a shift-reduce parser [17:28:52.0000] which doesn't really have a notion of "trying to satisfy" [17:29:33.0000] trying to satisfy is more of a top-down thing [17:29:46.0000] How can you do a bottom-up parse when what's legal as a token depends on the context you're in? [17:30:11.0000] Because you don't have to know exactly which context you're in [17:30:45.0000] I'm writing a recursive-descent parser, so I do know which rule I'm trying to apply... [17:30:50.0000] Like I said, if you've just parsed `a +`, you know that the following token can be a RegularExpressionLiteral but not a TemplateMiddle or a TemplateTail, so you know to use InputElementRegExp [17:31:39.0000] if you've just parsed `yield`, and you're in a template interpolation, you know that the next token could be a RegularExpressionLiteral or a TemplateTail, so you'd use InputElementRegExpOrTemplateTail [17:31:41.0000] etc [17:31:45.0000] ok, so, backing up a bit [17:32:15.0000] Are you specifically interested in having your parser cleave as close as possible to the spec, or are you just trying to write a parser? [17:32:35.0000] Is there a way to know, only from the previous tokens, which goal symbol I should be using? [17:33:32.0000] def importCall(_yield: Boolean, _await: Boolean) = str("import") ~ elem('(') ~ assignmentExpression(true, _yield, _await) ~ elem(')') [17:33:56.0000] There's a sample rule in the parser I've written so far, so I'm sticking pretty close to the spec. :-) [17:34:07.0000] what language is that [17:34:10.0000] Scala. [17:34:24.0000] parser combinators, woo [17:34:47.0000] Anyway, the answer is to your previous question is yes [17:35:23.0000] You know which syntactic contexts you might be in, which means you know if the next token can be a regexp, a template tail, or neither, which means you know which of the goal symbols to use [17:36:10.0000] both? InputElementRegExpOrTemplateTail. just regexp? InputElementRegExp. just template middle/tail? InputElementTemplateTail. neither? InputElementDiv. [17:36:47.0000] you might want to take a look at some existing parsers (acorn, babel, shiftjs) and see how they work [17:37:15.0000] OK. I know about TemplateTail, because if I don't have a previous, unclosed TemplateHead, that's out. [17:37:30.0000] devsnek ehh, so, the reason I was asking about if toddobryan was interested in sticking to the spec or not was, the spec is written for clarity and precision, not for ease of implementation [17:37:43.0000] so all the parser implementations don't look very much like the spec [17:38:06.0000] if you're trying to look like the spec you have to use different implementation strategies [17:38:32.0000] Is there something as easy as that for whether a Regexp is legal? [17:39:40.0000] I'm guessing I'll need a couple of flags during tokenizing that just flip on or off `isRegexpAllowed` and `isTemplateTailAllowed`. [17:40:13.0000] for regex literals you generally run over them with some very light rule that just basically recognizes / [ and ] [17:40:18.0000] mm, not quite as easy as that, I don't think [17:40:25.0000] and then pass it to the separate regex parser [17:40:36.0000] devsnek that happens later, not when trying to decide which lexical goal symbol to use [17:40:38.0000] it's a separate concern [17:40:52.0000] oh they meant if a regex is allowed [17:40:59.0000] not if it's valid [17:41:24.0000] toddobryan basically though a regexp is legal wherever an expression is legal; if the next token can't be an expression (without an intervening semicolon), then you can't have a regexp [17:41:49.0000] so, e.g., if you have just finished parsing an expression (other than `yield`), you can't have a semicolon [17:41:53.0000] *can't have a regexp, sorry [17:42:16.0000] btw if you haven't thought about ASI now is the time at which you'll need to think about ASI [17:42:28.0000] ASI? [17:42:33.0000] also no line terminator here [17:42:34.0000] automatic semicolon insertion [17:42:43.0000] https://tc39.es/ecma262/#sec-automatic-semicolon-insertion [17:43:04.0000] Yeah. That's next on the list. [17:44:56.0000] OK. So I guess I need to figure out how to keep track of whether a RegularExpressionLiteral is allowed. [17:46:05.0000] I think you always know at any point you'd ask the tokenizer for the next token [17:46:45.0000] like the normal way of writing a recursive descent parser, you have, I don't know, parseConditionalExpression or whatever [17:46:48.0000] Thanks for humoring me. I now understand what I was missing. [17:48:11.0000] and you call parseBinaryExpression and so on, and eventually end up at parsePrimaryExpression, and you're looking at the next token to determine which kind of primary expression it is [17:48:22.0000] Well, I was hoping to separate the parser and the tokenizer, but couldn't figure out how to do that without understanding which rules were applicable. [17:48:38.0000] and at that point you know that a regexp is legal, so when you ask for the next token, you know to ask for the regexp ones [17:48:56.0000] ah, yeah, you can't split them out because you don't know which goal symbol to use without knowing the syntactic context, unfortunately [17:49:32.0000] specifically, you don't know if `/` (or `/=`) is going to be the beginning of a regexp or a division without knowing the syntactic context [17:50:43.0000] anyway, good luck! if you make progress and are inclined to share you should post it; I would enjoy reading it [17:51:00.0000] I maintain a recursive descent JS parser written in Java, which... is a bit of a pain [17:51:01.0000] That makes perfect sense. So if I did want to write just a tokenizer, I'd need to include enough syntactic context to disambiguate. [17:53:16.0000] I can imagine. I tried creating a parser combinator library in Kotlin and gave up. The thing that makes them so nice in Kotlin is that you have the flexible syntax, but, and this is key, you can pass arguments by name in addition to by reference, so you don't have to deal with things like circular references and such. [17:53:32.0000] "so nice in Scala" I meant. [17:53:45.0000] Thanks for all the help! [17:54:40.0000] Yeah, the Java one does not get to use combinators [17:54:47.0000] Well, it could I guess, but it doesn't [17:55:29.0000] (it lives in https://github.com/shapesecurity/shift-java/blob/es2018/src/main/java/com/shapesecurity/shift/es2018/parser/GenericParser.java ) [17:55:55.0000] Thanks! [18:00:20.0000] toddobryan: thinking about it more, for a recursive descent parser I don't think you'd need to actually "keep track" of any state, as such, to know which of the four lexical grammar goal symbols to ask for [18:00:37.0000] it's always going to be obvious every time you ask for a token [18:01:16.0000] Yeah. It seems to work for parsing without knowing--what I can't do is tokenize. [18:01:35.0000] Can't tokenize ahead of parsing, right [18:02:21.0000] Because the syntactic grammar rules aren't written in terms of tokens--they're written in terms of input literals in lots of cases. [18:03:24.0000] Hm. I guess the way I'd put it is, the input literals are specializations of the nonterminals of the lexical grammar [18:03:55.0000] when the syntactic grammar says `if`, for example, that is an IdentifierName which has the contents "if" [18:04:05.0000] i.e. it is a particular kind of IdentifierName [18:04:22.0000] similarly when it says `(` that is a particular kind of Punctuator, etc [18:04:51.0000] you could write your tokenizer over the specializations, rather than over the full set; that is (afaik) what everyone actually does [18:04:57.0000] Yeah, I can see interpreting it that way. [20:15:39.0000] dang, I missed a grammar discussion [06:17:55.0000] I was looking at NamedEvaluation of anon functions within object literals [06:17:55.0000] and I was like gotcha - what if this key is a symbol? what will be to the fn name? [06:17:55.0000] And then found this - `set name to the string-concatenation of "[", description, and "]"` [06:17:55.0000] Now i understand how much of effort and details goes in to the specs. Just wanted to appreciate the contributors. [06:20:26.0000] (and i also wonder if there is a story behind this naming?) [14:21:25.0000] bendtherules: a story behind the name "NamedEvaluation" you mean? [16:28:09.0000] bradleymeck: is there a repo for string literal imports 2020-06-21 [17:01:03.0000] devsnek: not currently, forgot to ask for stage 1 so never made one [17:01:28.0000] oh [18:42:04.0000] jmdyck: i meant how symbol is converted to string using "[" + description + "]". [18:42:04.0000] That doesn't seem like a convention which is used in other places. [18:42:04.0000] And also someone noticed that if description is empty, it becomes just [], which might be confused with arrays. So, instead it's kept as just empty string. [18:43:03.0000] symbol isn't converted to string via "[" + description + "]" [18:43:47.0000] the symbol-to-string part happens at "Let description be name's [[Description]] value." [19:55:21.0000] jmdyck: i think we are talking about different sections of the spec. I am talking about - https://tc39.es/ecma262/#sec-setfunctionname [19:55:50.0000] that's what i was talking about too, see step 4.a [19:57:10.0000] Ok, got your point. Yes, technically 4 a gives the description which is a string. [19:57:10.0000] But that is not the final name which is set to the function [20:00:59.0000] perhaps you could restate your question/concern/point? [20:05:33.0000] My question was, is this a convention when a symbol is represented by a string? (description being surrounded by "[]") [20:05:56.0000] Is there any other place where a symbol is represented using this format? [20:08:03.0000] Well, that's easy enough to check for yourself: just look for how [[Description]] is used in the spec. [20:11:42.0000] Yes. So i saw that symbol.toString does - "Symbol(", desc, and ")". [20:12:01.0000] Is there any reason why these two representations are different? [20:13:19.0000] Dunno. Probably. [20:18:28.0000] Got it. I understand that there was probably some discussion around it. [20:18:28.0000] So if someone remembers such a discussion or can point to something - that will be helpful. [20:18:49.0000] (i looked in the notes and couldn't find with basic search) [20:21:30.0000] Looks like it was introduced in one of the early drafts of ES6, is November/December 2012 [20:21:36.0000] s/is/in/ [20:22:17.0000] Symbol, that is. [20:24:39.0000] Hmm, i found notes for symbol.description - but that's probably the public property [20:25:29.0000] And is there any old documentation for these es6 era discussions? [20:26:59.0000] theoretically, yes [20:28:57.0000] meeting notes would be posted to the es-discuss list [20:43:13.0000] Ok, i will try to look there [21:02:31.0000] bendtherules: it's a parallel of computed properties [21:03:06.0000] i.e. representing an expression in an identifier context [21:06:03.0000] Ok. So this convention was chosen because it looks like a computed property? [21:06:43.0000] I mean using square brackets around the description makes it look like a computed property [21:07:23.0000] yeah, all well known symbols have a description of the way you access them [21:07:45.0000] for example `Function.prototype[Symbol.hasInstance].toString()` will give you something like `'function [Symbol.hasInstance]() { [native code] }'` [21:32:32.0000] Isn't that a side-effect of this rule, though? [21:35:04.0000] Ok, i guess not. Because this is not a normal function, and wasn't created using `Function.prototype[Symbol.hasInstance] = function(){} `. [21:35:04.0000] It is just made to have a similar name [22:24:29.0000] bendtherules: what else would you expect `({ [Symbol.iterator]() {} })[Symbol.iterator].name` to be? [22:47:49.0000] ljharb: Well it could have been "Symbol(Symbol.iterator)" just like how `Symbol.iterator.toString()` works [22:49:26.0000] (i am not saying that that should be the case, but it's little odd that symbols can get "stringified" in 2 different ways - depending on .toString or NamedEvaluation [22:49:28.0000] ) [22:49:44.0000] fair [22:50:07.0000] bendtherules: i think the difference is that the toString is meant to tell you about the symbol, the name is meant to tell you about the function itself [22:53:26.0000] Hmm, makes sense. I am sure there would have been some discussion around this - so just wanted to find that. [22:54:09.0000] github.com/tc39/notes would likely have it [22:55:37.0000] I searched there, but couldn't find it. There is some discussion around Symbol.description - but I think that is just about internal desc getting exposed through public property [22:56:34.0000] There is also the es-discuss list, but it's little hard to search. Will try to search more later. [07:37:09.0000] bendtherules: you can run a git blame on the spec to see which commit introduced it [09:43:39.0000] devsnek: that predates git for the spec [09:43:48.0000] we moved to git somewhere between ES2015 and ES2016 [12:46:56.0000] specifically, for the start of ES2016 development 2020-06-22 [12:41:06.0000] pcg128 vs xorshift128+ for Math.random [12:41:28.0000] the pcg128 site makes a lot of claims but i also see v8 uses xorshift128+ 2020-06-23 [09:08:19.0000] Hello, I have a question about the Proxy object. As far as I understand, the goal of the proxy object was to provide security in JavaScript program communications. [09:08:29.0000] But, in the current specification, a proxy does not support to handle its internal slots such as [[RegExpMatcher]], [[DateValue]], and so on. Thus, once we wrap an object by a proxy, we lose a part of its identity. And, there are many cases to confirm an identity of a given object by checking the existence of such an internal slot (one of the [09:08:29.0000] examples is the use of the internal function "RequireInternalSlot"). [09:08:40.0000] I believe that everyone who is working on the specification aware of this issue. In the case of "Array.isArray", it checks its [[ProxyTarget]] when the given object is a proxy. [09:08:48.0000] But, I'm just wondering why they provide only a limited feature by a proxy. Is there any other solution to restrict the capability of such objects? Or, is there any reason not to handle the internal slots by a proxy object? [09:10:30.0000] proxies alone don’t provide the security guarantees you’re referencing; you also need a membrane implementation. [09:10:49.0000] Ah. Of course. I'm implementing membrane. [09:11:19.0000] But, once you pass an object via membrane, on the other-side, you lose the identity of a special object such as Date. [09:11:44.0000] because the proxy does not allow to bypass the internal slots of Date object. [09:12:36.0000] Simple example. [09:12:47.0000] ```var a = /abc/``` [09:12:55.0000] `var b = new Proxy(a, {})` [09:13:07.0000] `"abc".match(a) === true` [09:13:17.0000] `"abc".match(b)` throws an exception. [09:19:37.0000] Ah. I was disconnected. Is there anyone answered my question? sorry. [09:46:22.0000] Yoonseok: by "identity" you mean the internal slots that the builtins use; that means you have to replace all those builtins too [09:47:22.0000] Yoonseok: the design of Proxies is such that if you need to call a built-in method on the object, you have to wrap the method as well, so that e.g. `.match` does not call the original `RegExp.prototype.match`, but instead calls a wrapped version which can invoke the original one on the original target [09:49:50.0000] it's not just internal slots which behave this way: if you do `let created = new WeakSet; let factory = () => { let r = { m(){ console.log(created.has(this)); } }; created.add(r); return r; }; let a = factory(); let b = new Proxy(a, {}); a.m(); b.m();` you get `true` for the `a.m()` and `false` for the `b.m()` [09:50:34.0000] or, rather, I should say that internal slots - with the exception of Array, for some reason - behave the same way WeakMaps do (except for some cross-realm stuff which isn't usually relevant) [09:50:50.0000] where access to the internal slot requires having the object itself, not just a proxy for the object [09:52:27.0000] as to why things are the way they are, I'm not 100% sure. I think the idea was that internal slots should be like WeakMaps, and WeakMaps should work this way because they should be based on object identity, and a Proxy for an object should not have the same identity as the object because that would be confusing. [09:53:01.0000] by the way, take a look at https://github.com/ajvincent/es-membrane if you haven't yet; it's the most complete membrane implementation I know of [09:53:10.0000] p sure internal slots predate weakmaps, but i also don't know why things are the way they are [09:53:11.0000] and talks about some rationales [09:54:09.0000] ljharb yes but they also predate Proxies; the decision to make Proxies not access internal slots of theirr targets was not made until WeakMaps were being introduced [09:55:06.0000] true true, you are quite correct [09:55:59.0000] bakkot_ Thank you for the answer. I agree that we can provide a wrapped version of 'match' when the receiver is a proxy object. It might be one of practical solution. [09:56:16.0000] But, in my example, the receiver is the string. So, I called "String.prototype.match". [09:56:40.0000] In this case, we cannot simply provide a wrapped version because the receiver is not a proxy object. [09:57:01.0000] ah, yes. [09:57:54.0000] (well, technically you can I think, but it relies on a feature we are discussing removing, so I don't want to encourage you to take that route) [09:59:37.0000] ok. thank you for the responses. I would check the membrane implementation also. [09:59:47.0000] Yoonseok: the string, or the regex, is the proxy? [09:59:50.0000] I think it's only RegExps which have this problem (and maybe TypedArrays); it is unusual for internal slots to be accessed by code outside of the prototype [09:59:57.0000] ljharb the regex; see the code snippet above [09:59:58.0000] the regex is the proxy. [10:00:07.0000] Yoonseok: then you can define Symbol.match on the proxy [10:00:27.0000] ah. [10:00:58.0000] and that can define whatever semantics you want [10:01:06.0000] ljharb that was the bit I was alluding to re: features we want to remove [10:01:15.0000] actually though I am mistaken, we don't want to remove Symbol.match [10:01:19.0000] the part we're removing is in IsRegExp; String.prototype.match wouldn't change [10:01:32.0000] the proxy definitely still wouldn't pass IsRegExp with the change we want to make [10:02:01.0000] the proposed change is to RRegExp.prototype[@@match], I believe [10:02:32.0000] i was under the impression it was removing steps 2 and 3 in https://tc39.es/ecma262/#sec-isregexp [10:02:56.0000] hmm, can you use the subclass trick to make the proxy have a regex slot? [10:03:15.0000] I prefer not to think about that question :P [10:04:31.0000] haha fair [10:04:38.0000] :) [13:43:10.0000] we should add a binary not assignment operator :P [13:44:16.0000] oh that is kind of a weird gap [13:45:50.0000] just gotta add ≠ first [13:46:04.0000] ≠ is actually fewer keystrokes than != for me [13:46:16.0000] what unicode is that [13:46:30.0000] option-equals [13:46:36.0000] (on a mac) [13:46:38.0000] oh [13:46:40.0000] neat [13:46:51.0000] alt-8800 on a windows numeric keypad [13:46:57.0000] i could probably coerce my linux into doing that [13:47:00.0000] that... is more keystrokes [13:47:07.0000] very true. but it looks nicer 2020-06-24 [17:31:21.0000] yeah I guess I just assumed that indirect eval could never be returned to being direct eval but apparently that's false [17:33:06.0000] yeah, it's not a taint tracking model, it's much more brilliant where we just pick on one particular identifier :P [17:34:07.0000] you can rename `eval` to `evil` and then you don't have to use (0, eval) [17:38:43.0000] shu: lol [17:41:16.0000] am i the only one bothered by `promiseResolve` being after `promiseCapability` in that recent patch [17:42:27.0000] devsnek: but isn't that `evil` somewhat less evil than `eval` then [17:42:48.0000] a non-zero amount of evil is still evil [17:58:44.0000] bakkot_: devsnek: do you either of you have an opinion about what you expected eval?.() to be? [17:59:09.0000] not especially [17:59:29.0000] i can't construct any meaningful rule about direct/indirect evals [18:34:27.0000] wait till you hear about ablative eval [18:35:12.0000] eval, but every time you use it one random name in scope is removed [18:37:12.0000] that is the suffering passive [18:38:30.0000] et tu eval [19:16:56.0000] ugh I think I'll still create an issue before the PR just so the PR doesn't come off like an attack [20:10:20.0000] rkirsling: up to you, but i doubt that would be a problem [20:10:46.0000] ljharb: played it safe -- https://github.com/tc39/ecma262/issues/2062 https://github.com/tc39/ecma262/issues/2063 [06:10:20.0000] ljharb: https://www.python.org/dev/peps/pep-0622/ [08:41:52.0000] littledan: thanks for your comment in https://github.com/tc39/proposal-promise-any/issues/38 ... i didn't say anything, but i agree [08:42:01.0000] jridgewell: are there any major blocking points on private declarations recently [08:42:32.0000] Just waiting for private fields to ship before bringing it up again [08:43:21.0000] littledan: it bothered me a little bit that Mark didn't reply to https://github.com/tc39/proposal-promise-any/issues/38#issuecomment-634822974 [08:44:06.0000] I'd love to understand what invariant is being proposed [08:45:59.0000] jridgewell: was the `outer` contextual keyword just to remove the [] / simplify the grammar? [08:46:44.0000] or ... invoked, or whatever [08:47:26.0000] jorendorff: all those internal slots are not reflected to JS as first class APIs [08:47:29.0000] `outer` seems the simplest solution, and avoids me having to explain reification [08:48:11.0000] what is `outer` [08:48:12.0000] `class Foo { [#bar] = 1 }` seems too much like I've reified the key and can use it as a value [08:48:16.0000] jorendorff: the concern is around an internal slot not being able to be intercepted via a hook like other meta-object-protocol hooks [08:48:40.0000] oh for shared private fields [08:48:46.0000] can we not just reify them as values [08:48:46.0000] jridgewell: idc either way XD, it can be reified even if it isn't in the same value space! [08:48:56.0000] bradleymeck: I don't understand the "as first class APIs" part of the distinction [08:48:56.0000] lets not add value spaces [08:49:06.0000] https://github.com/tc39/proposal-private-declarations [08:49:21.0000] why do we need first class syntax for this aaaa [08:49:27.0000] jorendorff: fn.environment isn't a thing, basically even if the internal slot stores state it isn't able to be reached by user JS [08:49:39.0000] bradleymeck: [[Prototype]] has a getter (`.__proto__`) [08:50:00.0000] yes, and that has a Proxy MOP hook [08:51:02.0000] bradleymeck: [[ViewedArrayBuffer]] also has a getter https://tc39.es/ecma262/#sec-get-%typedarray%.prototype.buffer [08:51:06.0000] devsnek: to get me to stop using super override? [08:51:26.0000] bradleymeck: i mean why are we not just making them values [08:51:38.0000] jorendorff: yes, and a review of stuff was being done by caridy about all those cases as they break membranes. [08:51:53.0000] making a private version of every possible use of properties seems like a poor design path [08:52:17.0000] devsnek: because lack of prototype lookup would be hella confusing [08:52:30.0000] Making a private field value is difficult to get through [08:52:35.0000] it doesn't have to lack prototype lookup [08:52:42.0000] devsnek: i'd state it must [08:52:47.0000] why lol [08:52:51.0000] match fields [08:52:57.0000] ? [08:52:58.0000] also matches weakmaps [08:53:16.0000] we aren't making weakmaps we're making access control [08:53:21.0000] basically private lookups in JS haven't historically been delegated [08:53:44.0000] internal slots, private fields, weak map, all of them do not delegate [08:54:11.0000] so, it should be something else if it seeks to delegate [08:54:41.0000] first class access control doesn't exist in js yet [08:54:48.0000] i'm a little confused as to whether we're having one conversation or two [08:54:51.0000] what isn't first class? [08:54:55.0000] jorendorff: I am having 2 [08:55:04.0000] great [08:55:04.0000] I think there are 2 [08:55:18.0000] there was a discussion about private field syntax [08:55:25.0000] and i'm ranting about private symbols [08:55:59.0000] bradleymeck: so another example is that Map and Set are nothing *but* methods that provide access to data stored in private slots [08:56:39.0000] jorendorff: per your topic ECMA402 was at the SES meeting (2?) times ago and wanted to plug a similar hole [08:57:11.0000] jorendorff: yes, but the concern isn't about the values themselves it is the ability to intercept things [08:57:45.0000] bradleymeck: ok, intercept how? [08:57:47.0000] you can to some extent replace builtin methods to "patch" out the issue, but there is push back even within the Realms call (not just SES) [08:58:05.0000] jorendorff: replace methods with userland wrappers [08:58:07.0000] bradleymeck: it should be possible to express this clearly, as an adversarial game perhaps [08:58:39.0000] bradleymeck: but if there is a known technique for this (replace features on the builtin prototype) then it would work just as well for new things as for existing things [08:58:42.0000] various membranes have to do this where they freeze Map.prototype, but have to replace all the methods in order to intercept the values in/out [08:58:57.0000] jorendorff: it isn't actually applied to all kinds of membranes [08:59:24.0000] a lot of things like salesforce have much more minimal membranes and would wrap the Map as it crosses rather than each .get/.set [09:00:01.0000] i need to join an ses call at some point to ask about boxes for records [09:00:20.0000] its really the realms call [09:00:26.0000] like 50% of people there aren't using SES [09:00:41.0000] whoever it is that takes issue with boxes [09:00:50.0000] the concerns are just that you cannot intercept these internal slot lookups with a Proxy [09:00:57.0000] devsnek: thats the call you want to join [09:01:05.0000] which [09:01:23.0000] you can even add it to the agenda https://docs.google.com/document/d/1FZ95-NZIQE9fw3A8Sgcz2BKep6MlC_Kng0dlf1ehabQ/edit#heading=h.f8mfwudm59mq [09:02:03.0000] devsnek: its on the tc39 calendar "SES Strategy - Weekly" (had that name for years) [09:02:15.0000] > We had an engaging conversation with the champions of Records and Tuples, and the related proposals for deep paths and boxes. [09:02:28.0000] https://calendar.google.com/calendar/embed?src=mozilla.com_l7b50itpaa9bnrvr61nebqrne8%40group.calendar.google.com&ctz=America%2FChicago [09:02:33.0000] i guess there's no notes policy for these [09:02:46.0000] devsnek: they are recorded to youtube [09:02:59.0000] https://www.youtube.com/channel/UCpY91oQLh_Lp0mitdZ5bYWg/videos [09:05:27.0000] oh nice [09:06:16.0000] bradleymeck: it's a known flaw of proxies that they can't intercept internal slot lookups. but normally the result of that is that access fails (e.g. RequireInternalSlot is attempted on a proxy; it'll always fail and throw) [09:06:35.0000] bradleymeck: are we talking about some scenario in which access can't be blocked? [09:06:59.0000] my private symbols setup allowed you to pass symbols you wanted to intercept to the proxy constructor [09:07:00.0000] https://www.youtube.com/watch?v=QzASLxg2VIk [09:07:24.0000] maybe something similar could be done with private fields [09:07:25.0000] jorendorff: having a 2nd context that has a builtin and running it on the value as a receiver [09:07:30.0000] though they'd need to be reified in some way for that [09:07:57.0000] jorendorff: join the call this week as this topic is the only agenda item? [09:08:33.0000] i'm just explaining the concern to my understanding [09:08:51.0000] I'd so much rather have this written down somewhere [09:09:04.0000] but maybe we can work toward that [09:09:15.0000] jorendorff: it will be recorded at least [09:09:35.0000] bradleymeck: I don't see the Realms meeting on the TC39 calendar [09:09:40.0000] I see an SES Strategy meeting [09:11:04.0000] jorendorff: yes thats the call. it has had that name for years / has historically been the focus but SES as a proposal has started splitting up into other things like Realms/Compartments these days [09:11:45.0000] ugh, i can't make it this week, it's the one day i have an appointment i can't move :-P [09:12:17.0000] it would be cool if compartments had a hook for math.random [09:12:27.0000] either seeding it or just controlling it outright [09:12:37.0000] devsnek: just replace the global XD [09:12:56.0000] i guess [09:13:09.0000] Realms/Compartments are seeing pretty big pushback due to how much they do already so they got stripped down once [09:13:24.0000] couldn't it get access to the original by creating a new realm [09:13:54.0000] jorendorff: We're planning on discussing this topic in the SES call tomorrow [09:14:06.0000] devsnek: yes, you have to wrap the Realm constructor :-/ [09:14:09.0000] the SES Strategy meeting [09:14:20.0000] littledan: I can't make that meeting, unfortunately, but maybe someone from Moz can be there [09:14:23.0000] bradleymeck: also, seeding might be preferable for perf reasons [09:14:24.0000] we had a bunch of talks about how to not force people to wrap the realm constructor [09:14:46.0000] well its not that big a deal except for [09:14:49.0000] Date.now [09:14:50.0000] Math.random [09:14:53.0000] Symbol.for [09:15:03.0000] is there anything else [09:15:25.0000] there are a variety of things you have to wrap, but if you don't wrap then you have to make a composition model and some people didn't like that [09:15:51.0000] could have a hook for CreateRealm [09:16:06.0000] hm i guess we sort of already do with InitializeHostDefinedRealm [09:16:08.0000] could, but then it needs to nest [09:16:25.0000] yeah i mean realms created inside would automatically delegate to the parent for that [09:16:49.0000] a lot of the complaints are about nesting e.g. not having the same Web Settings object faces pushback from some Web standards [09:17:11.0000] bradleymeck: I still don't understand this: "having a 2nd context that has a builtin and running it on the value as a receiver" [09:17:12.0000] yea, the delegation is part of the complaints, because the deeper you go the more costly it is to create another realm [09:17:32.0000] bradleymeck: because applying any (non-generic) builtin to a proxy will just fail [09:17:41.0000] jorendorff: in web terms, make a same origin iframe and use the intrinsic getter function and call it on the value from the original frame [09:18:20.0000] membranes that just do deep freezing won't prevent that [09:18:28.0000] bradleymeck: if there is no Proxy around the value, then I don't understand the complaint that this can't be intercepted. Of course if you don't have a proxy there, you won't be intercepting anything [09:18:37.0000] if there is a Proxy around the value, the getter just won't work [09:18:47.0000] proposal: `import { #promiseState, #promiseResult } from 'std:private-fields/promise'; new Proxy(promise, handler, { intercept: [#promiseState, #promiseResult] })` [09:18:57.0000] jorendorff: agreed on both, but there are people not using Proxies around all values [09:19:07.0000] they only put proxies on the boundary [09:21:15.0000] bradleymeck: well ... I guess I don't understand why such users would complain about private slots [09:21:32.0000] if there's no proxy there... what is the expectation to be able to intercept something? [09:32:55.0000] ...Anyway, regardless of such details, a concrete statement of the desired rule would help [10:19:02.0000] If someone could refactor InitializeHostDefinedRealm to not be weird that'd be great [10:30:44.0000] devsnek: thanks, i'll add it [10:33:56.0000] annevk: what's the weirdness? [10:41:00.0000] shu: the way you have to allocate global and global this are rather awkward [10:47:22.0000] here's my idea: CreateRealm(global, thisValue) [10:47:36.0000] performs all the intrinsic allocation and setting of globals and stuff [10:47:54.0000] if a host needs to add additional properties after that it can just do that, no need to specifically make a step for it [10:56:50.0000] devsnek: i think those need to be abstract closures that do the actual creation [10:57:11.0000] since you presumably want to allocate the new stuff inside the create Realm, not outside of it [10:57:17.0000] the created* [10:57:29.0000] i'm not entirely sure what you mean [10:57:34.0000] annevk: how does that sound? passing in closures? [10:59:22.0000] do you mean a closure for performing arbitrary host setup of the realm? [10:59:31.0000] i'm not sure why that needs to be part of the spec [10:59:49.0000] devsnek: when hosts want to create a global object for a new Realm, it seems most natural to create the global object in the scope of the created Realm instead of somewhere else [11:00:05.0000] OH i see what you mean [11:00:16.0000] yeah that makes sense [11:02:03.0000] shu: yeah, something like that would be good [11:02:59.0000] annevk: i'm still working on a relatively large PR that separates out the notion of a "host" as an implementation that layers with ecma262 via some set of enumerated host APIs instead of any arbitrary implementation-defined/dependent points [11:03:09.0000] annevk: i'll put this on the queue after that [11:03:11.0000] \o/ [11:26:09.0000] jsc people, why are all the releases missing https://webkitgtk.org/jsc-built-products/x86_64/release/ [11:26:24.0000] rkirsling: ^ [11:29:43.0000] webkitgtk is its own project so you'd have to ask an Igalian that works on it [11:36:27.0000] the JSCOnly builders don't have an archive upload step (https://build.webkit.org/waterfall?category=misc) but GTK build archives are located at the usual archive.webkit.org (e.g. https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Build%29/builds/35021/steps/transfer-to-s3/logs/stdio) [11:36:47.0000] so at a glance, I don't think anything for webkitgtk.org would happen automatically [11:39:11.0000] https://gc.gy/60728945.png [11:44:49.0000] I don't know what that's coming from [11:48:59.0000] rkirsling: archives.webkit.org uploads a zip with README.md containing that [11:49:05.0000] luckily i found a way to get around that [11:49:13.0000] https://github.com/devsnek/esvu/commit/988ed899cd126f5faab8f63634c7459f7d2c182d [11:49:15.0000] oh I see [11:52:42.0000] these archives are huge 2020-06-25 [01:32:06.0000] bakkot_: shouldn't the argument to fontcolor then be called colour? [01:42:41.0000] annevk debatable; there it makes sense to match the name of the methood [01:43:11.0000] I can totally believe there are inconsistencies though [02:24:23.0000] which locale is Referer spelled in? [02:25:20.0000] devsnek: I've pinged internally about this [02:26:57.0000] littledan: the [sic] locale [02:27:33.0000] maybe we should put this in the lang tag for all web specs [02:27:44.0000] littledan: also responsible for URI, white-space, and Keep-Alive [02:27:50.0000] en-us-SIC [02:27:52.0000] it's a variant [02:28:01.0000] en-GB-oxendict-SIC for ECMAScript [02:28:08.0000] right [02:28:41.0000] there needs to be a variant tag or extension key for oxford comma. oxendict doesn't quite describe it. This is a well-established need for Intl.ListFormat [02:29:25.0000] Indeed, you might well want the Oxford comma and also spell color as color [02:29:46.0000] exactly [02:30:05.0000] en-GB-oxendict-SIC-u-com-oxford [07:17:30.0000] I need some help in understanding how function hoisting works, following the spec. [07:17:30.0000] From a light read, i thought - function gets declared during static semantics of its outer function body. [07:17:30.0000] But this example i saw recently doesn't match up then. If you have function declaration within `if (false) {function abc() {} } `, then it doesn't get declared ;but if it's within if true, then it gets declared and hoisted to closest function scope. [07:18:24.0000] How does it actually work? [07:24:12.0000] Is it like - if the statementlist directly contains function declaration, then declare it during static semantics (and hence hoisted). But if it's within a construct like if-else, then let it get declared during runtime semantics (hence not hoisted).? [07:31:00.0000] bendtherules: you have entered the dark space of annex B https://tc39.es/ecma262/#sec-functiondeclarations-in-ifstatement-statement-clauses [07:31:14.0000] web compatibility yay [07:32:17.0000] so this is something special about if-else only? [07:33:05.0000] If i declared function within say, a while loop (or some other construct), wouldn't that get moved to parent function? [07:36:43.0000] bendtherules: no, the end of that section points to more web compat stuff that affects hoisting [07:37:11.0000] https://tc39.es/ecma262/#sec-block-level-function-declarations-web-legacy-compatibility-semantics is probably the worst part of the spec to understand IMO [07:38:29.0000] Ahh, nice. I will try to understand that. [07:38:29.0000] If someone can provide a TLDR or point to some blog post, that would also be very helpful [07:39:40.0000] (just being lazy, haha 😀 ) [07:41:15.0000] Also, can you tell if engine262 would implement things like this? [07:43:54.0000] devsnek: ^ [07:47:33.0000] bendtherules: at the moment engine262 ignores annex b [07:47:45.0000] anything else is fair game [07:48:24.0000] ok. Thanks 👍 [08:00:42.0000] bakkot_ ljharb devsnek: I've been thinking about how to spec builtin generators for the iterator helpers proposal, I had a thought of couple designs and wanted to make sure I was on the right path: https://gist.github.com/avandolder/b852641a4c218cf8a98f1ad4aa133a96 [08:01:07.0000] I'm pretty sure design 1 was basically what had been agreed upon IIRC [08:01:45.0000] avandolder: what we can technically do is [08:02:12.0000] bendtherules: rkirsling wrote a good summary at https://dev.to/rkirsling/tales-from-ecma-s-crypt-annex-b-3-3-56go [08:02:32.0000] avandolder: we can use the existing section to create two duplicates [08:02:44.0000] and from there, the operations on them should work normally since the internal slots have the same names [08:06:00.0000] so define the builtin generators as having GeneratorState/Context slots then using the already defined operations on them? [08:07:33.0000] yeah that seems simplest to me [08:13:24.0000] i think the only potential issue with that would be if the builtin generator object is directly available, then you could call `%GeneratorPrototype%.next(builtinGen)` [08:13:59.0000] maybe no one will notice :P [08:14:08.0000] we could add checks in the exposed functions i guess [08:14:19.0000] if the builtin generators are always kept in an internal slot then that would [08:14:26.0000] n't be possible to call [09:47:40.0000] avandolder: see https://github.com/tc39/ecma262/pull/2045 as well [10:12:16.0000] alright. assuming that PR is adjusted like jackworks said, and merged, would that be the approach to go with? having the iterator methods return an object that spec-wise is a brand-checked object with generator internal slots? [10:12:46.0000] brand-checked *iterator [10:23:15.0000] avandolder: assuming that PR will convince the editors that it's a viable approach for both all current iterator-producers, as well as the iterator helpers proposal, then that seems like the approach we'll go with yeah [12:02:55.0000] bakkot_, rkirsling - Thanks for the article. This was much more easy to understand, specially with the historical context. [12:12:16.0000] :D [13:43:18.0000] ljharb: wait so JS itself is predicted to have a "heat death"? :p [13:44:14.0000] rkirsling: you might say that when people stop working on js it will become cold [13:45:20.0000] seems like a reasonable metaphor [13:46:09.0000] rkirsling: you are welcome to define that as you wish [13:48:56.0000] now I just have Uptown Funk stuck in my head tbqh [14:12:13.0000] devsnek: rkirsling: leobalter: https://webkitgtk.org/jsc-built-products/x86_64/release/ is now back up! [14:12:20.0000] yehaw [14:12:36.0000] sorry for the inconvenience, it was an infra snag. [14:13:06.0000] esvu installed it [14:13:09.0000] all seems well [14:13:20.0000] yaaaay! [14:13:35.0000] i wish js engine debug clis would support moving the cursor left and right [14:13:43.0000] history would be cool as well [14:14:16.0000] devsnek: I mean, you're optimizing for a very very narrow niche here I guess [14:14:42.0000] hey man i'll take left/right [14:14:50.0000] but maybe you should make a simple C++ prompt library [14:14:56.0000] i had a CL way back in the day to add readline to d8 [14:15:01.0000] it was totally ignored [14:15:04.0000] lol [14:15:07.0000] F [14:16:36.0000] nice, I didn't realize that that was in fact the right place [14:18:06.0000] hm i guess it was linenoise instead of readline https://chromium-review.googlesource.com/c/v8/v8/+/1012404 [14:18:50.0000] devsnek: well, you can see the OWNERS of `d8` [14:18:53.0000] and talk to them? [14:19:19.0000] i CC'd an owner [14:19:20.0000] :( [14:19:28.0000] but oh well it doesn't matter that much [14:19:35.0000] 🤷 [14:19:43.0000] I tend to be a tad more shameless sometimes. [14:20:25.0000] if i was gonna do it today i would vendor node to replace d8 [14:21:36.0000] really? [14:21:43.0000] isn't that too heavy a debug shell? [14:21:50.0000] why does d8 need a stdlib lol [14:22:19.0000] it is surprising that "nice" CLI behavior is DIY [14:23:01.0000] POSIX has readline [14:23:04.0000] which is pretty good [14:23:29.0000] it even supports persistent history [14:23:35.0000] I mean JSC does have the things you described [14:23:50.0000] jsc has none of it [14:23:53.0000] left/right arrow support and (session-specific) history [14:24:13.0000] https://gc.gy/60825255.png [14:24:19.0000] me hitting arrow keys [14:24:38.0000] maybe Mac specific? [14:25:08.0000] sec lemme try on mac [14:25:26.0000] using the brilliant power of esvu [14:25:28.0000] doesn't allow Ctrl+left/right though [14:25:41.0000] which is frequently annoying [14:25:55.0000] wow it is supported [14:25:59.0000] why doesn't it work on linux [14:26:45.0000] there's a #if HAVE(READLINE) [14:27:19.0000] where is READLINE defined [14:27:26.0000] tbh what is HAVE [14:28:45.0000] https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/Platform.h [14:28:49.0000] HAVE_READLINE isn't defined for linux [14:29:14.0000] https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/PlatformHave.h [14:29:36.0000] is the new location but yeah just flagged for Mac and iOS [14:30:06.0000] down lower there's an if DARWIN or LINUX that would be a good place to put it [14:32:05.0000] I think they're separated out so that you can change the platform setting for each HAVE instead of vice-versa [14:32:28.0000] https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/PlatformHave.h#L75-L77 is redundant though because it's also Darwin [14:45:20.0000] I just aliased d8 to `rlwarp d8` [14:46:16.0000] holy shit that's brilliant [14:46:46.0000] this changes EVERYTHING [14:47:04.0000] lol nice [14:49:53.0000] what's rlwarp? [14:50:14.0000] rlwrap wraps a program's stdin through readline [14:50:52.0000] https://linux.die.net/man/1/rlwrap [14:54:55.0000] ah [14:55:24.0000] maybe i'll add a feature to esvu to support wrapping engines with it [14:56:21.0000] next step is to make rtlwrap [14:56:27.0000] oops this isn't tdz [14:58:56.0000] ljharb: gonna say this here 'cause I don't really want to derail the issue thread but if we made an error for optional call of %eval% in particular that'd be a runtime error since even `eval()` might turn out not to be %eval% [14:59:41.0000] only in sloppy mode [15:01:49.0000] anyway recognizing that an error could be a third path is not unworthwhile but I think both ways of realizing it would be icky [15:04:21.0000] rkirsling: ah right, true enough 2020-06-26 [19:34:44.0000] > rlwarp [19:34:44.0000] WHY HAVE I NEVER HEARD OF THIS? [01:02:26.0000] Hello. Is there any reliable mechanism to identify a type of a given function object? I want to know whether this function is normal, generator, async, and so on. [01:26:43.0000] Oh. *mechanism* seems misleading. I want to find a reliable way to identify a type of a function. [06:59:58.0000] Yoonseok: they do have different prototypes, but in general they could always return stuff and act as other things, e.g. it is common for a normal function to return the promise of an async function [07:00:12.0000] Yoonseok: so, even if you know the type, it generally isn't useful [07:01:16.0000] fun stuff also happens when sometimes we have seen functions passed into node's builtins with null prototypes via Object.setPrototypeOf(()=>{}, null) [07:01:26.0000] so even prototypes aren't necessarily a good route [07:02:09.0000] yes. Indeed, prototypes is mutable. So, it is not reliable. [07:02:39.0000] hm. i'm thinking about "it generally isn't useful". [07:03:20.0000] for a given function, i want to provide a kind of secure layer that filter out leaking a secret by return value. [07:04:28.0000] but, without knowing the type of a given function, it is not possible to provide a secure layer for the function. (mostly, this layer is a wrapper function). [07:05:27.0000] in the case of generator, it returns a generator object, and you can call the it by generator.next(), which is out of my scope. [07:06:43.0000] indeed, it is not surprising even though js does not support a feature to identify a type of object. [07:07:43.0000] but, in other cases, such as Date, RegExp, we can observe the type by applying the object to "Date.prototype.getTime" or "RegExp.prototype.test". [07:08:39.0000] but, I really cannot find it for generator or async functions. [07:10:55.0000] in practice, we can apply `Function.prototype.toString`, but it is not standard (so, XS or JerryScript does not return its content), [07:11:12.0000] moreover, Function.prototype.bind removes it. [07:13:48.0000] bradleymeck anyway. thank you for the response. :) [07:15:47.0000] Yoonseok: I mean, Function.prototype.bind.call(fn) will give you a *new* function with the proper prototype [07:15:59.0000] ah. [07:16:01.0000] but it won't be useful for determining how the return value works [07:16:13.0000] normal functions can return iterators/promises/etc. [07:16:51.0000] or wait, not it won't it just inherits [07:16:56.0000] my brain is waking up still [07:16:56.0000] it is correct. okay. i had some assumption. [07:21:25.0000] okay. i will check it first. I'm thinking about whether I can implement a membrane that allows me to pass a generator. [07:56:43.0000] bradleymeck thank you. i think that you're right. such type information is not useful. they are all just a function that returns a different type of values. [07:59:06.0000] Yoonseok: in general what Membranes if they are crossing a barrier do for such things is to wrap all the return values if they are objects if you look at lightning web components, es-membrane, or SES [08:03:44.0000] i'm looking at the current limitation of membranes. since membrane relies on proxy feature and proxy feature does not allow to access internal slots, membrane does not guarantee the identity of objects (here, identity means internal slots). for example, if a regular expression object o is passed via membrane, you cannot use "abc".test(o) because o [08:03:44.0000] is not a regular expression object anymore. [08:03:50.0000] I think it is the same for the generator function. [08:04:52.0000] generator function returns a generator object, and (of course, no one really want to use this) if anyone want to call the generator object gfn by `(function*(){}).constructor.prototype.prototype.next.apply(gfn)`, it will fail. because gfn is not a generator object (it is a proxy). [08:05:57.0000] ah. when gfn is obtained by a generator function passed via the membrane (the barrier). [08:06:39.0000] I thought that there is a way to improve it if we know the type of a function. but, you're right. we can't even if we know the type. [08:12:38.0000] uh. i really want to rewrite whole sentences. sorry for the mess sentences. :/ [09:27:37.0000] ljharb: i can't tell what your suggested change does [09:27:47.0000] i hate that github won't highlight it [09:28:05.0000] spells additionally properly [09:28:49.0000] oh cool 2020-06-27 [17:24:08.0000] if anyone has opinions -> https://github.com/tc39/proposal-iterator-helpers/issues/107 [17:24:40.0000] i don't think there's really enough of a consistency in Constructor() and Constructor.from() to draw a useful pattern [17:24:50.0000] s/draw/have/ [17:29:56.0000] I find the OP pretty compelling [17:30:01.0000] Array.from(array) makes a new array [18:51:37.0000] bakkot_: Constructor() often makes a new instance as well, so idk [18:52:03.0000] if i had to choose what i think is most likely to create a new instance of something i'd choose the thing that looks like a constructor [18:52:34.0000] I agree with that but I don't think that means I would expect .from to_not_ make a new instance of the thing [19:01:30.0000] if "from" is the problem maybe it just needs a different name [07:05:33.0000] Is there any repo which contains the https://tc39.es/ecma262 built page? [07:08:09.0000] I am looking to extract the mapping json contained in "#menu-search-biblio" of ecma262 website [07:09:02.0000] I understand it is possible to get that after doing build, but if it's already available in some repo - that'll be easier [07:10:37.0000] try the ecma262 repo, in the gh-pages branch [07:11:43.0000] Yes, that works. Thanks [15:13:07.0000] ljharb: i think String.prototype.indexOf step 8 should be removed [15:23:27.0000] Why is the clause for StringIndexOf in "ECMAScript Language: Source Code" ? It doesn't have anything particularly to do with Source Code. [15:40:45.0000] how does one convert a utf16 codepoint to utf8 octets [15:41:19.0000] no such thing as a "utf16 codepoint", I think. [15:42:19.0000] s/utf16// [15:43:01.0000] how in the spec, you mean? [15:43:26.0000] like in js how would one achieve such a functionality [15:45:03.0000] you mean, how do express the UTF-8 transform in JS? [15:46:04.0000] like what algorithm would be used to utf8 encode a codepoint [15:49:25.0000] I'm not sure how to answer other than: the UTF-8 encoding algorithm. [16:09:53.0000] > If the two most significant bits in B are not 10, throw a URIError exception. [16:10:09.0000] does this mean if the two most significant bits are not 1 and 0, respectively? [16:17:42.0000] devsnek: would have to; are you worried about an endianness assumption? [16:17:52.0000] no [16:18:13.0000] i'm trying to implement the uri functions in engine262 [16:30:53.0000] devsnek: almost certainly yes [16:32:10.0000] a fun article on the design of a general recoverable parser: https://marijnhaverbeke.nl/blog/lezer.html [16:41:26.0000] oh this does look fun 2020-06-28 [22:17:57.0000] devsnek: why? [22:18:42.0000] devsnek: position can be negative, or larger then len [06:08:49.0000] ljharb: this step [06:08:54.0000] > Let searchLen be the length of searchStr. [07:38:06.0000] step 9, why should that be removed? [07:38:27.0000] i want to pull more things out of the last step, not squish more into it [08:03:50.0000] ljharb: it's step 8 [08:03:58.0000] are we looking at different specs or something [08:04:35.0000] the one on GitHub? [08:04:49.0000] or are you looking at an outdated snapshot [08:05:08.0000] tc39.es/ecma262 https://usercontent.irccloud-cdn.com/file/0wgqBxhO/Screenshot_20200628-100449.jpg [08:05:54.0000] hmm, i am not sure why i saw the wrong step number the last 2 times i looked [08:05:58.0000] step 8 in indexOf, step 9 in lastIndexOf [08:06:10.0000] (step 10 in includes) [08:06:12.0000] ah i must have jumped to lastIndexOf and not realized it [08:06:31.0000] devsnek: same reply tho; i want more explicit steps pulled out of the last one, not less [08:06:53.0000] searchLen isn't used anywhere [08:06:59.0000] I'm not sure what that means [08:07:01.0000] ohh hmm [08:07:11.0000] lol maybe i was looking at an outdated snapshot. One sec. [08:08:02.0000] ok yes, that step in both indexOf and includes need to be removed [08:08:06.0000] good catch [08:08:27.0000] my eslint caught it :D [08:09:08.0000] (my static analysis doesn't detect unused metavars yet) [08:09:31.0000] construct a CFG [08:09:42.0000] convert to SSA [08:09:45.0000] DCE [08:09:58.0000] TLA overflow [08:11:58.0000] ljharb: (maybe you missed this from yesterday:) Why is the clause for StringIndexOf in "ECMAScript Language: Source Code" ? It doesn't have anything particularly to do with Source Code. [08:12:22.0000] i don’t think anyone thought much about it, is my guess [08:12:40.0000] if there’s a better place i think it’d be fine to move it there [08:13:45.0000] we should put it back into String#indexOf and have other algorithms invoke String#indexOf steps X-Y [08:16:53.0000] you forgot the "/s" [08:22:27.0000] I'll submit a PR to move it (prob today) if no-one else does. [08:23:40.0000] (Looks like in PR #2009, it was always in clause 10, I just never noticed it before.) 2020-06-29 [13:47:06.0000] ljharb / bterlson / whoever else is championing pattern matching: https://www.python.org/dev/peps/pep-0622/ [13:52:21.0000] bakkot_: thanks, devsnek pinged me about it last week and it's mentioned in an issue on the repo already :-) i'll add it to the readme at some point [13:52:27.0000] ah, good good [13:53:06.0000] just copy paste it into the spec text proposal done ez [13:53:30.0000] (/s) [13:56:53.0000] > Created: 23-Jun-2020 [13:56:54.0000] wao [14:12:35.0000] :%s/Python/ECMAScript/g problem solved [14:17:18.0000] oughtta call ECMAScript proposals ESPs since they're like peeking into the future [14:17:30.0000] oops not tdz [15:11:20.0000] is this valid `/(?.)[\k]\k/` [15:11:25.0000] https://github.com/acornjs/acorn/issues/927 [15:25:17.0000] devsnek: https://github.com/tc39/ecma262/issues/2037 [15:25:46.0000] tl;dr is no per spec, yes per the shipping implementations [15:30:25.0000] neat [15:30:29.0000] i don't even know what \k does [15:31:59.0000] oh wow \k is cool [15:41:08.0000] I think you mean it's "kool" 😎 [16:02:27.0000] Oh phew, the intention of that regex is to match any char, then a "\" or "k", then the first character again? [16:07:06.0000] but \ inside [] needs escaping, right? [16:07:15.0000] so [\k] would at best be [k], no? [16:07:37.0000] yeah https://github.com/tc39/ecma262/issues/2037#issuecomment-641602774 [16:08:43.0000] I don't think that regex can be said to have an intention behind it [16:08:53.0000] except to exercise an edge case 2020-06-30 [17:06:33.0000] Oooh, that pattern-matching PEP is making many of the same choices we appear to be settling on for JS, nice. [17:13:38.0000] Big difference being that we're planning on separating out destructuring and class-based matching, while they're sticking them together, implicitly destructuring with either a sequence or mapping destructure written like a constructor call. [17:17:05.0000] (That ends up being quite weird imo; it's designed to let you make a match clause *look like* a constructor, but it actually matches off of the returned value, which can have no relation whatsoever to how you'd actually construct a value.) [17:17:16.0000] But still, otherwise it mostly accords with our thoughts, nice. [17:19:51.0000] Hm, actually the PEP's inability to match based on an expression result is problematic; you can't, say, match against a range. [17:20:22.0000] other big difference is that it's statement-position-only [22:02:57.0000] ljharb: i think your changes to asyncfromsynciteratorprototype changed the length properties of the methods, that's expected right? [22:03:04.0000] s/expected/intended/ [22:05:15.0000] yes, since the methods aren’t observable it’s non-normative [22:06:26.0000] ah yeah true [22:09:25.0000] statement-position only is very Pythonic, I don't consider that to be a significant difference here (that is, not something we should draw conclusions about JS from) [22:10:39.0000] agree [22:11:27.0000] in a way that Rejected Ideas section is some of the most interesting content [07:05:14.0000] rbuckton: https://github.com/rbuckton/proposal-enum/ would you like to move this to stage 1? I'd like to see ADT enum comes true 🌟 [15:03:18.0000] jackworks: I'd also love to see this. rbuckton if you'd like to revive this I can lend a hand