| 00:00 | <jmdyck> | so you're thinking of a grammar parameter that doesn't affect the grammar at all, it's just there to convey some info to a deep node? |
| 00:02 | <Bakkot> | grammar parameter doesn't seem like the way to go to me |
| 00:02 | <Bakkot> | I would just spell it out in prose |
| 00:04 | <devsnek> | not sure how to spell it out with prose |
| 00:04 | <jmdyck> | same as it is now? |
| 00:04 | <devsnek> | "evaluate script except make sure that isProtoSetter is false"? |
| 00:04 | <devsnek> | jmdyck i'm working on moving __proto__ into the main spec |
| 00:05 | <Bakkot> | "except that in the semantics for PropertyDefinitionEvaluation of PropertyDefinition : PropertyName `:` AssignmentExpression steps 3 and 4 are replaced by 1. Let _isProtoSetter_ be *false*" |
| 00:05 | <Bakkot> | or whatever |
| 00:05 | <devsnek> | scary |
| 00:05 | <devsnek> | hmm |
| 00:05 | <jmdyck> | link to PR? |
| 00:05 | <devsnek> | what if i added a new definition for PropertyDefinition : __proto__ : AssignmentExpression |
| 00:05 | <Bakkot> | and then in the actual algorithm add a subsequent step which says `1. Note: the above steps are replaced during JSON.parse` |
| 00:05 | <devsnek> | i haven't uploaded it yet |
| 00:05 | <jmdyck> | k |
| 00:05 | <devsnek> | going to in a minute |
| 00:06 | <Bakkot> | the "Replaced by" thing is a thing we already do elsewhere |
| 00:06 | <Bakkot> | see e.g. https://tc39.es/ecma262/#sec-built-in-function-objects-construct-argumentslist-newtarget |
| 00:06 | <Bakkot> | it's one of the things ecmarkup now explicitly supports |
| 00:06 | <devsnek> | unfortunate but ok |
| 00:06 | <Bakkot> | (well, the reference to steps, anyway) |
| 00:08 | <jmdyck> | you maybe don't need an "is replaced by" thing |
| 00:09 | <jmdyck> | wait, __proto__ in main spec, but it's still 'normative optional'? |
| 00:10 | <devsnek> | yeah |
| 00:10 | <jmdyck> | hm, then I should probably wait to see |
| 00:10 | <devsnek> | here https://github.com/tc39/ecma262/pull/2125 |
| 00:11 | <devsnek> | jmdyck: to be clear, the syntax __proto__ is required |
| 00:11 | <devsnek> | the accessor __proto__ is optional |
| 00:13 | <jmdyck> | inconsistent whether hyphen between '__proto__' and 'is-proto-setter-true' |
| 00:14 | <jmdyck> | ref has it, def doesn't |
| 00:15 | <jmdyck> | Also, step-ids usually start with "step-". (Not sure if ecmarkup complains if they don't.) |
| 00:15 | <jmdyck> | (or is it ecmarkdown) |
| 00:15 | <devsnek> | ecmarkuparound |
| 00:16 | <jmdyck> | ok, i understand original the question now. |
| 00:17 | <devsnek> | idk how i'm going to implement this "replace step" thing in engine262 😢 |
| 00:17 | <devsnek> | `globalThis.dontproto = 1` |
| 00:18 | <jmdyck> | i have a different suggestion |
| 00:18 | <devsnek> | sure |
| 00:18 | <jmdyck> | it'll take me a while to get the wording |
| 00:18 | <devsnek> | no rush |
| 00:25 | <jmdyck> | In the alg, start the new code with a step something like: If this |PropertyDefinition| is within a |Script| that is being evaluated for JSON.parse (see "step-json-parse-parse"), then \n Let _isProtoSetter_ be *false*. |
| 00:25 | <devsnek> | interesting |
| 00:26 | <jmdyck> | there's a sliver of precedent for the wording |
| 00:26 | <jmdyck> | https://tc39.es/ecma262/#sec-resolvebinding step 3 |
| 00:26 | <devsnek> | i hate that |
| 00:26 | <jmdyck> | heh |
| 00:26 | <devsnek> | we need to get rid of that |
| 00:28 | <devsnek> | is there a way to build without the linter |
| 00:29 | <Bakkot> | just omit --lint-spec |
| 00:29 | <Bakkot> | `npm run build-only` will do it |
| 00:29 | <devsnek> | oh ok |
| 00:30 | <Bakkot> | next version of ecmarkup will be a little more helpful in telling you the options you want |
| 00:30 | <jmdyck> | Well, if you figure out a nice way to "get rid of that", you can apply it my suggestion. |
| 00:31 | <devsnek> | i don't have a better suggestion |
| 00:31 | <devsnek> | we should make emu-xref self closing |
| 00:32 | <jmdyck> | I don't think we can. ad hoc elements can't be. |
| 00:32 | <devsnek> | i mean we can emit them with </emu-xref> |
| 00:32 | <devsnek> | but in terms of authoring we could make them self closing |
| 00:32 | <jmdyck> | or at least, not in html. spec.html doesn't *have* to be html |
| 00:32 | <Bakkot> | we use an off-the-shelf HTML parser |
| 00:32 | <Bakkot> | don't really want to write my own at the moment |
| 00:33 | <jmdyck> | hah, I wrote my own in a few hours when I got tired of the off-the-shelf one. |
| 00:33 | <devsnek> | pr it into ecmarkup |
| 00:34 | <jmdyck> | it isn't written in js/ts |
| 00:34 | <Bakkot> | also it has to either emit the format jsdom expects or we also have to rewrite jsdom |
| 00:35 | <Bakkot> | or at least the relevant bits |
| 00:35 | <Bakkot> | or write an adapter I guess |
| 00:35 | <jmdyck> | my parser's pretty simple, because spec.html uses a very well-behaved subset of html. |
| 00:35 | <jmdyck> | but that's all it has to deal with, so why not? |
| 00:35 | <devsnek> | sounds like my rewrite of engine262 |
| 00:48 | <jmdyck> | devsnek: s/Else, If/Else if/ |
| 00:56 | <jmdyck> | Also, although I agree you don't need that sentence at [id="step-json-parse-parse"] any more, it might still be helpful to readers to point out that this evaluation is special-cased at <step-link>. |
| 00:58 | <jmdyck> | Or maybe not. Maybe I prefer it without. |
| 01:57 | <DerekNonGeneric> | is anyone able to review (and hopefully merge) my PR to the TC39 site? It fixes UI bug on mobile that is somewhat unsightly https://github.com/tc39/tc39.github.io/pull/206 |
| 01:59 | <devsnek> | is the spec backwards https://gc.gy/64297783.png |
| 02:08 | <devsnek> | fixed it by flipping the alternative parser inside out https://gc.gy/64298329.png |
| 04:44 | <devsnek> | mathiasbynens: do you know a good way to map from the unicode property tables in the spec to the unicode-x packages? |
| 04:44 | <devsnek> | for example ID_Start/True -> Binary_Property/ID_Start |
| 04:53 | <mathiasbynens> | devsnek: https://github.com/mathiasbynens/regexpu-core/blob/b031e2721608f517588a97b06f847f015d65bc6d/rewrite-pattern.js#L43-L55 |
| 04:53 | <devsnek> | is it literally just that one ternary |
| 04:54 | <mathiasbynens> | no, see the surrounding code as well |
| 04:54 | <mathiasbynens> | this is to go from source text to the unicode-x packages btw, not from the spec tables necessarily (but i suppose that's what you wanted?) |
| 04:55 | <mathiasbynens> | binary properties are always Binary_Property/* |
| 04:55 | <devsnek> | well i'm implementing the spec line for line so i end up with the result of UnicodeMatchProperty and UnicodeMatchPropertyValue |
| 04:55 | <devsnek> | handleLoneUnicodePropertyNameOrValue looks similar though |
| 04:56 | <mathiasbynens> | if there's Foo=Bar then you look for `${unalias('Foo')}/${unalias('Bar')}` |
| 04:56 | <mathiasbynens> | else it's `Baz`, which is `General_Category/Baz` |
| 04:56 | <devsnek> | or Binary_Property/Baz, right |
| 04:56 | <mathiasbynens> | right that's why you handle those first |
| 05:20 | <devsnek> | mathiasbynens: seems to be working, thanks 👍🏻 |
| 05:21 | <mathiasbynens> | devsnek: yay 👍🏻 |
| 05:21 | <devsnek> | although bundling these sets into engine262 may prove to be a problem |
| 05:25 | <Bakkot> | because of size? |
| 05:25 | <Bakkot> | just make it a peerdep or whatever |
| 05:26 | <devsnek> | well i want to use it in browser too |
| 05:27 | <Bakkot> | you can load the peerdep when someone asks for it |
| 05:29 | <devsnek> | trying to build it used 6gb of heap and then crashed 🎉 |
| 05:29 | <Bakkot> | psh |
| 05:29 | <devsnek> | how do real engines pack this data |
| 05:30 | <Bakkot> | as my undergrad algorithms professor liked to say, algorithms are for people who can't order more RAM |
| 05:30 | <rkirsling> | bags of holding? |
| 05:32 | <devsnek> | hm i guess its just part of icu |
| 05:33 | <Bakkot> | cat /lib/icu | emscripten |
| 05:33 | <devsnek> | oh no |
| 14:47 | <jackworks> | https://github.com/NiceLabs/proposal-arraybuffer-equals |
| 14:47 | <jackworks> | does anyone interested in champion this? 🤔 |
| 18:44 | <shu> | jackworks: IMO it needs better motivation. a byte-wise comparison of two entire buffers is easy enough to write and doesn't seem very common |
| 18:46 | <bradleymeck> | i might also be concerned with concurrent access for shared stuff |
| 18:48 | <shu> | i assumed it was for ABs, not SABs |
| 18:48 | <shu> | that thing ain't gonna work good for SABs |
| 18:53 | <devsnek> | ljharb: https://gc.gy/64358629.png |
| 18:55 | <ljharb> | devsnek: lol it’s a start, but I’d really suggest splitting those into a different PR, since i bet it’ll take a bit to workshop that, and to work out Kevin and my disagreement about optionality |
| 18:55 | <rkirsling> | how about angled red-and-yellow stripes :P |
| 18:55 | <devsnek> | now we're talkin |
| 18:55 | <devsnek> | i don't know how to do that but if someone knows how |
| 18:55 | <devsnek> | that sidebar being red/yellow stripes would be awesome |
| 18:56 | <devsnek> | ljharb: they're in every engine, if the only thing contentious is the note we put on them then i don't think it needs a separate pr |
| 18:57 | <ljharb> | i don’t want bad things required if they can be optional instead, even if everyone ships them already. |
| 18:58 | <devsnek> | so like |
| 18:58 | <devsnek> | would you want to make with statements normative optional |
| 18:58 | <devsnek> | in theory |
| 18:58 | <bradleymeck> | if the ecosystem can rely on the behavior that cannot be removed from engines for compat reasons, we shouldn't take stances on stylistic choices of which API to use |
| 18:59 | <devsnek> | yeah i mean like |
| 18:59 | <devsnek> | the spec says the how |
| 18:59 | <devsnek> | not the why |
| 19:02 | <bradleymeck> | we do take stances on things that break semantic stuff (e.g. document.all typeof and boolean nightmare) |
| 19:07 | <ljharb> | devsnek: I’m specifically talking about non-grammar |
| 19:07 | <devsnek> | idk what the difference is |
| 19:08 | <ljharb> | i can’t use js to delete the grammar |
| 19:08 | <devsnek> | i'm not sure what you mean |
| 19:08 | <ljharb> | or polyfill it, etc |
| 19:08 | <devsnek> | the question is not polyfillability |
| 19:08 | <devsnek> | the question is |
| 19:08 | <devsnek> | "is this a thing that is in the js language" |
| 19:08 | <devsnek> | the reality answer is "yes" |
| 19:08 | <ljharb> | I’m saying i see syntax and api as different categories |
| 19:09 | <Bakkot> | bradleymeck the stance that we took on document.all was for implementations, not for users |
| 19:09 | <ljharb> | and I’m still skeptical that there’s new code that uses defineGetter and friends |
| 19:09 | <devsnek> | we don't only support new code |
| 19:09 | <devsnek> | 1js right? |
| 19:09 | <Bakkot> | ljharb I have seen defineGetter incode written within the last six months on web properties |
| 19:10 | <bradleymeck> | Bakkot: i'd agree with that statement but we likely wouldn't have said anything about style |
| 19:10 | <ljharb> | 1js gets invoked arbitrarily. it didn’t make Module and Script unambiguous, E.G. |
| 19:10 | <bradleymeck> | the point was document.all semantics are problematic but needed to be explained |
| 19:10 | <ljharb> | Bakkot: what for? |
| 19:10 | <Bakkot> | ljharb defining a getter? |
| 19:10 | <ljharb> | Bakkot: like why couldn’t they rely on the syntax form, or O.dP |
| 19:10 | <Bakkot> | they could have but they didn't |
| 19:10 | <Bakkot> | welcome to javascript |
| 19:10 | <ljharb> | if you’re saying it’s an education problem then that imo supports my position |
| 19:11 | <ljharb> | people use bad things until they learn it’s bad. signals in the spec help with that. annex b helps with that |
| 19:11 | <Bakkot> | I am saying that __defineGetter__ will be with us forever |
| 19:11 | <Bakkot> | and no implementation intending to run existing JS can avoid shipping it |
| 19:12 | <Bakkot> | so we should not make it optional |
| 19:12 | <Bakkot> | I also disagree with the idea that the spec should be used for this kind of pedagogy. I do not think people who are putting __defineGetter__ in new code are reading the spec. |
| 19:12 | <ljharb> | I’m not convinced that’s true. |
| 19:12 | <ljharb> | node is trying to remove the proto mutator, for example |
| 19:13 | <ljharb> | (and yes, they won’t read the spec, but all the articles they read, if any, will be informed by it) |
| 19:13 | <Bakkot> | at the expense of breaking a bunch of code, which they're willing to do |
| 19:13 | <ljharb> | and being optional affords them that leeway to experiment |
| 19:13 | <devsnek> | to be clear large swaths of the ecosystem stop working when you get rid of __proto__ |
| 19:13 | <devsnek> | the most downloaded package on npm uses __proto__ |
| 19:14 | <Bakkot> | they can do that experiment whether or not it is optional |
| 19:14 | <ljharb> | no they can’t |
| 19:14 | <Bakkot> | yes they can? |
| 19:14 | <Bakkot> | what |
| 19:14 | <ljharb> | or rather, not without being out of compliance |
| 19:14 | <Bakkot> | right |
| 19:14 | <Bakkot> | which they can do |
| 19:14 | <ljharb> | i have zero cares for an engine that’s out of compliance |
| 19:14 | <Bakkot> | with zero cost |
| 19:14 | <Bakkot> | well |
| 19:14 | <ljharb> | what i care about is that they can experiment while remaining in compliance |
| 19:14 | <Bakkot> | tbh your prioritize seem... extremely... bad. |
| 19:14 | <ljharb> | how so? |
| 19:14 | <devsnek> | backwards |
| 19:15 | <Bakkot> | I think we are missing a _lot_ of background assumptions here |
| 19:15 | <Bakkot> | like what a spec is for |
| 19:15 | <ljharb> | it matters *a lot* to people what the spec says. I’m not saying the spec shouldn’t conform to reality in the general case, ofc |
| 19:15 | <devsnek> | fwiw ljharb |
| 19:16 | <devsnek> | if we're "experimenting" we aren't worried about compliance |
| 19:16 | <ljharb> | but for each place where we change the spec to match reality, we should be evaluating what the *ideal* would be, weighing if reality can change to match it or not, and doing the least bad compromise |
| 19:16 | <Bakkot> | sure |
| 19:16 | <ljharb> | devsnek: i doubt node would remove something by default that’s required by the spec |
| 19:16 | <Bakkot> | reality cannot get rid of __defineGetter__ |
| 19:16 | <Bakkot> | so, we should match reality |
| 19:16 | <devsnek> | ljharb: we deleted Atomics.wake |
| 19:16 | <ljharb> | ? |
| 19:17 | <ljharb> | Bakkot: I’m not sure that’s true. does xs need it, for example? |
| 19:17 | <devsnek> | xs has it |
| 19:17 | <Bakkot> | ljharb does xs intend to run existing code? |
| 19:17 | <ljharb> | Bakkot: “reality” isn’t solely defined by the corpus of existing js code imo |
| 19:17 | <Bakkot> | ljharb so like. |
| 19:17 | <Bakkot> | backing up a step. |
| 19:17 | <ljharb> | k |
| 19:17 | <ljharb> | devsnek: not sure what you mean about Atomics.wake |
| 19:18 | <devsnek> | node deleted Atomics.wake before it was removed from the spec |
| 19:18 | <devsnek> | as part of a semver major cycle |
| 19:18 | <ljharb> | why? |
| 19:18 | <devsnek> | because reality said it was being changed to notify |
| 19:19 | <ljharb> | ok so, anticipating an upcoming change |
| 19:19 | <ljharb> | I’m not being super pedantic here about “compliance” |
| 19:19 | <devsnek> | although i'm noticing that firefox still has Atomics.wake present |
| 19:19 | <ljharb> | if something isn’t expected to be non-required, then i would not expect node to ever remove it by default |
| 19:20 | <Bakkot> | ljharb your stance appears to be "I personally would prefer people not use this widely-implemented thing, whose use has no negative security implications, so we should not make it normatively required". I disagree with this entire category of argument. |
| 19:20 | <Bakkot> | I do not think that argument is relevant, at all, to whether something should be normatively required. |
| 19:20 | <devsnek> | to be clear, we're marking __proto__ optional because of security, not because we dislike it |
| 19:21 | <Bakkot> | devsnek right, that's the point of that qualification |
| 19:21 | <ljharb> | Bakkot: i think that “would this have ever been in the language if it had gone through a proper design process” is a reasonable question to ask when considering optionality |
| 19:21 | <Bakkot> | I am fine with keeping the __proto__ setter normative optional |
| 19:21 | <Bakkot> | ljharb why? |
| 19:22 | <ljharb> | because history, intention, and design matter when looking at usability and thinking about users? |
| 19:22 | <devsnek> | they do, this is why mdn has a big red box at the top of the __defineSetter__ page |
| 19:22 | <ljharb> | I don’t think it is appropriate or sufficient to only consider spec versus reality here, I’m concerned about users’ mental models |
| 19:23 | <devsnek> | but that doesn't have any bearing on the specifics of how __defineSetter__ is implemented |
| 19:23 | <Bakkot> | those things matter when communicating to users which parts of the language they should use, but that is not what we are discussing. we are discussing what things in the spec are optional for implementations. |
| 19:23 | <ljharb> | devsnek: and I’m glad we’re retaining that big red box in the spec when moving it out of annex b (making it more explicit, even) |
| 19:24 | <ljharb> | Bakkot: i suspect we have different experiences informing how much what the spec says actually matters to inexperienced users |
| 19:24 | <devsnek> | i don't think anyone here is against a note saying they suck |
| 19:24 | <ljharb> | Bakkot: in my experience, those users don’t read the spec, but they cite it *often* when justifying some decisions |
| 19:24 | <ljharb> | Bakkot: often because they saw the citation in a book or blog post |
| 19:25 | <ljharb> | if you’ll pardon the term, there is a very objective trickle-down effect that happens from putting discouragements or encouragement in the spec |
| 19:25 | <Bakkot> | again, we are discussing which features implementations are permitted to omit, not editorial notes about style preferences |
| 19:26 | <ljharb> | currently, anything in annex b “might not be there”, and so that leads people to avoid using them. Not all people, surely, but many. |
| 19:26 | <Bakkot> | I am happy to have a separate conversation about whether we should annotate the features in the spec we personally dislike with notes saying that |
| 19:26 | <ljharb> | that some of the features are always everywhere doesn’t change the effect. |
| 19:27 | <Bakkot> | ljharb those features _will in fact be there_. those people are being _misled_ by the spec's current totally false implication that they might not |
| 19:27 | <Bakkot> | I am strongly opposed to this philosophy of lies-to-children as a principle guiding normative decisions about what is in the spec |
| 19:27 | <ljharb> | yes, misled to everyone’s benefit |
| 19:27 | <ljharb> | not that i want to mislead people |
| 19:27 | <ljharb> | but my priority is the outcome |
| 19:28 | <devsnek> | i'm not sure what this has to do with the normative requirements of the spec |
| 19:28 | <Bakkot> | I am unwilling to lie to people just to get them to stop using a feature I dislike which has no negative security consequences. |
| 19:29 | <Bakkot> | I don't think the spec should do so either. |
| 19:29 | <Bakkot> | especially since the spec is also used by implementors. |
| 19:30 | <devsnek> | the point of the spec is to clearly communicate the requirements of an implementation to someone making an implementation |
| 19:41 | <shu> | reading backlog: strong agreement with Bakkot here |
| 19:42 | <rkirsling> | yeah, I think that's well-conveyed: it is an implementation guide, not a usage guide |
| 19:42 | <shu> | > I am happy to have a separate conversation about whether we should annotate the features in the spec we personally dislike with notes saying that |
| 19:43 | <shu> | ^ i am not. the answer to that is "no we should not" |
| 19:54 | <ljharb> | well yeah, obviously the way Bakkot phrased that none of us would be on board with it, myself included |
| 19:54 | <ljharb> | rkirsling: the spec is very much a usage guide as well, whether that's intended or not |
| 19:55 | <devsnek> | how is it a usage guide |
| 19:55 | <devsnek> | it just says that things exist |
| 19:55 | <ljharb> | it's used as one |
| 19:55 | <ljharb> | and what arguments they take, and what types/shapes those arguments can take |
| 19:55 | <rkirsling> | but if a user grabs the spec, wouldn't it just be to prove that, e.g. "V8 is doing the wrong thing"? |
| 19:55 | <shu> | ljharb: link me some examples |
| 19:55 | <ljharb> | rkirsling: i'm not saying users grab the spec |
| 19:56 | <ljharb> | rkirsling: i'm saying that the things users read are written by people who cite the spec (and nobody looks up the citations) |
| 19:56 | <ljharb> | shu: off the top of my head i don't have any, but i will do so when i find some. |
| 19:56 | <ljharb> | shu: the majority of my opinion here is from many, many years of helping inexperienced JS programmers on IRC |
| 19:57 | <devsnek> | i don't understand what advice can be offered by reading the spec |
| 19:57 | <ljharb> | and the increased popularity of transpilation, and "compat tables" and whatnot, mean that average users are much more aware of what's standard and what's not |
| 19:57 | <ljharb> | shu: devsnek https://twitter.com/rauschma/status/644511281421111296 |
| 19:57 | <ljharb> | to name one prominent author. |
| 19:58 | <devsnek> | so one time in 2015 some guy misrepresented annex b |
| 19:58 | <Bakkot> | I believe that these people exist. I just do not think this fact should guide normative decisions about what is required. |
| 19:58 | <ljharb> | https://twitter.com/phoddie/status/1150911833944907776 |
| 19:58 | <ljharb> | devsnek: it's not a misrepresentation tho |
| 19:58 | <ljharb> | devsnek: that is how it's often been talked about in plenary by various delegates. |
| 19:58 | <shu> | that's the kind of misconception we're trying to combat by inlining it |
| 19:58 | <ljharb> | Bakkot: i think that's a fine discussion to have |
| 19:58 | <ljharb> | shu: imo it's not a misconception. |
| 19:58 | <shu> | it is a misconception |
| 19:59 | <devsnek> | in the tweet you linked |
| 19:59 | <devsnek> | XS found that it couldn't be a useful implementation without implementing those annex b things |
| 19:59 | <Bakkot> | either we are intending to guide usage, in which case we should the conversation about annotating the features in the spec we personally dislike, or we are not. in neither case is the right outcome that we use this input to guide normative decisions in the spec. |
| 19:59 | <ljharb> | in ES5: https://es5.github.io/B.html "This non-normative annex suggests uniform semantics for such properties without making the properties or their semantics part of this standard." |
| 19:59 | <Bakkot> | it seem very strange to me to say "I want to guide usage, but I only want to do so by making normative decisions about what's optional, to the detriment of implementors" |
| 19:59 | <ljharb> | Bakkot: guiding usage doesn't require "personal" dislike. |
| 19:59 | <Bakkot> | ljharb right, that note turned out to be wrong |
| 20:00 | <rkirsling> | yeah that's actually a super helpful point toward promoting that handful including __proto__ |
| 20:00 | <ljharb> | Bakkot: how is it a detriment to implementors for things to be optional? |
| 20:00 | <rkirsling> | (that = Peter's tweet) |
| 20:00 | <Bakkot> | ljharb because they are in fact not |
| 20:00 | <Bakkot> | ljharb if you are writing an implementation, and omit __defineGetter__, your implementation will not be able to run the millions of lines of JS which exist |
| 20:00 | <ljharb> | "in fact" depends on what code is run in the implementation |
| 20:00 | <ljharb> | not every implementation needs to be able to run "all code in the ecosystem" |
| 20:01 | <Bakkot> | not everything needs to be a JS engine at all! |
| 20:01 | <Bakkot> | you can be a different language, that's fine |
| 20:01 | <Bakkot> | however |
| 20:01 | <ljharb> | how much JS code is there that has no browser globals or node modules/require, etc |
| 20:01 | <ljharb> | and that also uses these annex b things |
| 20:02 | <ljharb> | do you have any defineGetter examples that don't rely on a nonstandard module system, node core modules, browser globals/the DOM, or the ability to have i/o? |
| 20:02 | <devsnek> | what does that have to do with anything |
| 20:02 | <ljharb> | console.log isn't part of the standard either |
| 20:02 | <devsnek> | it probably should be |
| 20:02 | <devsnek> | but that's a separate convo |
| 20:02 | <ljharb> | devsnek: i'm saying that if the argument is "the spec must have X because everyone defacto has to implement X anyways" only works if the code in question is actually 262-portable |
| 20:02 | <ljharb> | if it has `window` in it, it's not |
| 20:03 | <ljharb> | eg |
| 20:03 | <Bakkot> | fricking _nashorn_ found they had to add __defineGetter__ |
| 20:03 | <devsnek> | ouch |
| 20:03 | <ljharb> | lol fair, but any chance that's because nobody in the ecosystem was writing code for nashorn, and they wanted to be able to ride on the back of the existing ecosystem? |
| 20:04 | <shu> | ljharb: i don't understand what point you're trying to make |
| 20:04 | <Bakkot> | I am sure they did want to ride on the back of the existing ecosystem, and people's experience writing for it! that is the point of using JS instead of a new language in the first place! that is _why we have a standard_! |
| 20:04 | <ljharb> | shu: i mean the underlying point is that i think that things in annex b carry a connotation of being both deprecated and optional, and for API things, i do not want to lose that without careful consideration. |
| 20:04 | <devsnek> | "nashorn didn't want to create a new ecosystem they wanted to be part of the existing ecosystem" |
| 20:04 | <devsnek> | ugh what bakkot said |
| 20:05 | <ljharb> | Bakkot: people like using RN and react because the knowledge transfers even though the code largely does not |
| 20:05 | <ljharb> | Bakkot: you don't need to use *any* specific existing code to have it be useful to have a JS engine. |
| 20:05 | <ljharb> | (obviously the vast majority would be pretty reusable) |
| 20:05 | <ljharb> | but in the RN ecosystem, the packages that are shared between RN and react web are not that plentiful. |
| 20:06 | <ljharb> | and it's still useful that RN is javascript |
| 20:07 | <devsnek> | hermes, an engine written solely for running reactive native, has __defineSetter__ |
| 20:07 | <devsnek> | react native* |
| 20:08 | <shu> | ljharb: okay. and we're saying your understanding of the connotation is a misconception. arguing here doesn't seem particularly productive because it has mostly been telling of your philosophical disagreement with what a standard ought to do, and what a standards developing organization ought to do, as Bakkot noted earlier |
| 20:08 | <ljharb> | hermes has relatively inconsistent support for parts of the standard, altho it's improving, and it's not clear to me which parts they added for parity with jsc (the previous RN engine) or out of necessity from existing RN code. |
| 20:08 | <ljharb> | shu: whether it's a misconception is not an objective thing, and i'm not the only one in the committee with it. i agree the philosophical debate isn't likely to be productive. |
| 20:09 | <Bakkot> | the philosophical debate is the only relevant debate here |
| 20:09 | <devsnek> | i thought at the october meeting we explicitly came to agreement on how annex b didn't imply the things shouldn't exist and that we should try to reconcile them with the main spec |
| 20:10 | <shu> | ljharb: not implying having misconceptions it not limited to you, no |
| 20:10 | <ljharb> | devsnek: see the notes, one of the bulletpoints is my explicit objection to indiscriminately hoisting API things out of annex b |
| 20:10 | <shu> | oops, too many negations there |
| 20:10 | <ljharb> | lol i think i know what you meant |
| 20:10 | <devsnek> | right there are things in annex b that would break certain requirements we have of the main spec |
| 20:10 | <devsnek> | like the regex grammar |
| 20:10 | <ljharb> | devsnek: grammar things i'm on board with hoisting up |
| 20:10 | <Bakkot> | ljharb the notes do not in fact say that |
| 20:11 | <ljharb> | Bakkot: "For non-grammar, the previous consensus holds but we keep in mind JHD’s request that we clearly mark things that we want to deprecate or discourage, perhaps in prose where Annex B once stood" |
| 20:11 | <ljharb> | https://github.com/tc39/notes/blob/7b2de881081abd34b02bc87bcdb662fd97555795/meetings/2019-10/october-1.md#conclusionresolution-4 |
| 20:11 | <Bakkot> | right |
| 20:11 | <ljharb> | ie, plenary only discussed grammar |
| 20:11 | <Bakkot> | i.e., you want there to be non-normative notes about things being discouraged |
| 20:11 | <Bakkot> | this is very different from "my explicit objection to indiscriminately hoisting API things out of annex b" |
| 20:11 | <ljharb> | ok |
| 20:12 | <ljharb> | we did not explicitly discuss whether inlined api things would remain optional |
| 20:12 | <ljharb> | but the implication to me was that most things would remain optional |
| 20:12 | <ljharb> | either way the only thing we had consensus for, and the only thing the agenda item was about, was annex b grammar |
| 20:13 | <devsnek> | i'm not against things being optional |
| 20:13 | <devsnek> | __proto__ is optional |
| 20:13 | <devsnek> | but optional requires a good reason |
| 20:13 | <Bakkot> | anyway, let me repeat myself above. my stance continues to be: either we are intending to guide style, in which case we should have the conversation about annotating all the features in the spec we personally dislike, or we are not, in which case it is absurd to say that something should be normative optional because we want people not to use it. |
| 20:13 | <ljharb> | change requires consensus. all things in annex b are already optional. |
| 20:14 | <ljharb> | Bakkot: you keep saying "personally" dislike |
| 20:14 | <ljharb> | Bakkot: that's a strawman |
| 20:14 | <ljharb> | Bakkot: we could annotate things the *committee* dislikes, sure. which we already do. |
| 20:14 | <ljharb> | just not everything. |
| 20:14 | <Bakkot> | ljharb uh |
| 20:14 | <devsnek> | we definitely have not taken a vote on whether we subjectively like __defineGetter__ |
| 20:14 | <ljharb> | what i mean is, "personally" implies that individuals get to stamp their individual dislike on things |
| 20:15 | <ljharb> | which obv is not what anyone would want |
| 20:15 | <devsnek> | that seems to be what you've been arguing |
| 20:15 | <Bakkot> | ok, s/personally/collectively/, whatever |
| 20:15 | <ljharb> | devsnek: then i've done a bad job of expressing my points |
| 20:15 | <Bakkot> | my stance continues to be: either we are intending to guide style, in which case we should have the conversation about annotating all the features in the spec we collectively dislike, or we are not, in which case it is absurd to say that something should be normative optional because we want people not to use it. |
| 20:15 | <ljharb> | everything in annex b is already specifically optional, and "being in annex b" already conveys "deprecated" |
| 20:16 | <ljharb> | a PR is editorial if it doesn't change the former (and possibly the latter, but we already seem to have consensus on adding the latter explicitly when inlining). it's normative if it does change the former, and we'd need consensus on that. |
| 20:16 | <devsnek> | and we have evidence that for implementations, __defineSetter__ is not actually optional |
| 20:16 | <ljharb> | i see no evidence that it being optional has been a detriment, though |
| 20:17 | <devsnek> | its detrimental to existence of the spec |
| 20:17 | <devsnek> | the spec's reason for existing |
| 20:17 | <devsnek> | is to tell implementers what they need to do |
| 20:17 | <devsnek> | if it doesn't do that it is failing |
| 20:17 | <Bakkot> | it is detrimental to lie to people because we want other people not to use a feature because we think it's stylistically bad |
| 20:17 | <ljharb> | and everyone implemented it already, so it seems that the spec making it optional hasn't stopped anyone from doing what they need to do |
| 20:18 | <Bakkot> | there continue to be new implementations with surprising frequency |
| 20:18 | <shu> | there has also been anecdotes of implementations learning, the hard way, that they have to implement it, like in nashorn and hermes? |
| 20:18 | <ljharb> | then there should be lots of examples of where it was a huge inconvenience/disruption for these things to be marked as optional |
| 20:18 | <Bakkot> | every time one of those happens those people end up finding out, usually the hard way, that the spec is lying to them |
| 20:18 | <ljharb> | shu: "hermes has it" isn't that; nashorn "having to add it" is indeed such an anecdote |
| 20:18 | <Bakkot> | ljharb I ran into this _perrsonally_! |
| 20:18 | <ljharb> | on? |
| 20:18 | <Bakkot> | I maintain a JS engine for my company! |
| 20:19 | <Bakkot> | when I wrote it the first time it did not get annex B right because I didn't know it was important! |
| 20:19 | <ljharb> | ok, so you built the engine without annex b, and how quickly ran into problems? |
| 20:19 | <devsnek> | the reproduction code for the function name issue used __lookupSetter__ |
| 20:19 | <devsnek> | i couldn't run it in engine262 |
| 20:19 | <ljharb> | "it wasn't right the first time" is not really a reliable rubric for good code :-p |
| 20:19 | <shu> | ??? |
| 20:19 | <Bakkot> | I gotta walk away from this conversation, I'm sorry. |
| 20:19 | <devsnek> | that's *the* rubric for the spec |
| 20:19 | <shu> | are you directly refusing to acknowledge implementers' lived experience? |
| 20:20 | <ljharb> | i mean like, was it exceedingly more difficult to implement annex b because you didn't realize at the beginning that you had to implement it |
| 20:20 | <shu> | i am baffled |
| 20:20 | <ljharb> | shu: no, i'm trying to understand it |
| 20:20 | <shu> | i am seeing no evidence of that |
| 20:20 | <ljharb> | shu: so far what i'm hearing is "i didn't know i needed it, so i didn't build it. then i found out, and built it" |
| 20:20 | <devsnek> | a bunch of implementers said "this was confusing" and you're saying "lol thats not so bad" |
| 20:21 | <ljharb> | devsnek: Bakkot and you have said you found it so, totally. please link me to examples of others? |
| 20:21 | <devsnek> | you linked one of xs |
| 20:21 | <devsnek> | shu shared the one about nashorn |
| 20:21 | <ljharb> | i'm not trying to marginalize those two examples, i'm just trying to understand them |
| 20:21 | <ljharb> | the xs one doesn't say anything about confusion |
| 20:21 | <shu> | Bakkot shared the one about nashorn, not me |
| 20:21 | <ljharb> | it's just a statement of fact about which subset of annex b xs implements |
| 20:22 | <shu> | ljharb: the understanding is that you take them at face value, in that one of the central points of a standard is to facilitate ease of entry into the market for newcomers |
| 20:22 | <ljharb> | engines make mistakes in implementations all the time, i don't see "i didn't do it right the first time" as evidence of confusion |
| 20:22 | <ljharb> | or rather, as strong evidence of it |
| 20:22 | <shu> | and here are people trying to enter the market place, and found out the standard did not facilitate that as well as it could have |
| 20:22 | <ljharb> | i understand that |
| 20:22 | <shu> | it is not for you to dismiss them and say "they didn't do it right the first time"? |
| 20:22 | <shu> | because they did -- the standard says it's optional |
| 20:22 | <ljharb> | i'm not trying to dismiss anything |
| 20:22 | <shu> | but the market says it is not |
| 20:24 | <ljharb> | i think that case can be made for individual parts of annex b, but not for all of it as a whole. i'm convinced of it with proto, and i'm not convinced with the defineGetter family. |
| 20:25 | <devsnek> | what would it take for you to be convinced |
| 20:26 | <ljharb> | that's a reasonable question to ask and i'll try to come up with an answer for it |
| 20:26 | <devsnek> | fwiw every non-browser js engine i'm aware of implements __defineGetter__ and co |
| 20:27 | <devsnek> | actually i take that back i found one, espruino |
| 20:28 | <ljharb> | i would certainly be interested to see examples of code that has been unchanged for long enough that it won't likely ever be updated, uses defineGetter and friends, and isn't part of a website. |
| 20:28 | <ljharb> | any new code using it is pretty likely to be easily updated to use defineProperty |
| 20:29 | <devsnek> | why should it be updated |
| 20:29 | <ljharb> | right now? because it's depending on optional parts of the spec. |
| 20:30 | <devsnek> | but every js engine supports it |
| 20:30 | <devsnek> | and it has no security issue |
| 20:30 | <ljharb> | the spec doesn't mention security issues either |
| 20:30 | <devsnek> | right but we change the spec to deal with security issues |
| 20:30 | <ljharb> | "every engine supports an optional thing" doesn't make it a safe thing to rely on forever, since it's optional |
| 20:30 | <devsnek> | for example SharedArrayBuffer global being optional |
| 20:31 | <ljharb> | right, which means that you can never safely write code that depends on it being present |
| 20:31 | <devsnek> | normal humans don't care what the spec says, they care if their code runs |
| 20:31 | <ljharb> | that such code may exist doesn't force us to make it required |
| 20:46 | <Bakkot> | either we are intending to guide style, in which case we should have the conversation about annotating all the features in the spec we collectively dislike, or we are not, in which case it is absurd to say that something should be normative optional because we want people not to use it. normative optionality is not the correct tool to guide style. |
| 20:47 | <Bakkot> | we should not lie to implementors about whether they need to implement something in order to run JS as it exists just because we want users not to use a feature. that is contrary to the core purpose of having a standard. |
| 20:53 | <devsnek> | +1 |
| 21:44 | <devsnek> | weakref are merged |
| 21:44 | <devsnek> | js is finally good |
| 21:51 | <devsnek> | ljharb: "Let agentRecord be the surrounding agent's Agent Record" |
| 21:51 | <devsnek> | this seems.... not right? |
| 21:52 | <ljharb> | in the weakrefs PR? |
| 21:52 | <devsnek> | wait did this add a new thing |
| 21:52 | <ljharb> | cc shu/Bakkot re the weakrefs PR ^ |
| 21:52 | <devsnek> | no i guess it just |
| 21:53 | <devsnek> | i guess this isn't wrong |
| 21:53 | <devsnek> | unexpected change though |
| 21:54 | <shu> | devsnek: why does that seem not right? |
| 21:54 | <devsnek> | it seemed not right before i realized there was a refactoring to make it right |
| 22:04 | <devsnek> | %WeakRef% and %FinalizationRegistry% aren't in the intrinsics table |
| 22:06 | <ljharb> | whoops |
| 22:06 | <ljharb> | i'll put up a PR to add them |
| 22:11 | <ljharb> | devsnek: https://github.com/tc39/ecma262/pull/2126 |
| 22:13 | <devsnek> | when did the whole "agent record" thing happen |
| 22:16 | <ljharb> | devsnek: https://github.com/tc39/ecma262/pull/522 ? |
| 22:16 | <Bakkot> | reminder that https://searchfox.org/ecma262/source/spec.html |
| 22:18 | <devsnek> | the hell |
| 22:18 | <devsnek> | how did i never notice that agent records are a thing |
| 22:18 | <ljharb> | they must have been secret agent records |
| 22:18 | <ljharb> | … i'll show myself out |
| 22:19 | <devsnek> | wow you made jmdyck leave |
| 22:27 | <ljharb> | lol |
| 22:42 | <devsnek> | the new native function matcher test takes like 10 minutes to run in engine262 |
| 22:42 | <devsnek> | big speed |
