2019-12-03 [23:23:56.0000] I've been doing some experiments with radix trees for unicode name literals in strings [23:24:24.0000] it looks like a serialized map in memory would be around 800kb [23:25:29.0000] significantly less than the 4mb of a hashmap [23:26:43.0000] mathiasbynens: ^ [23:27:12.0000] devsnek: makes sense [23:27:36.0000] i don't remember the exact numbers you were talking about before, but does that sound more reasonable? [23:27:57.0000] i mean, less is better [23:28:05.0000] i didn't provide any specific numbers [23:28:17.0000] but imho, even that 800 kb doesn't pay for itself [23:28:55.0000] this would be a feature that minifiers "undo" anyhow [23:29:48.0000] yeah, that's not a trivial cost to users, relative to the benefit they'd get [23:29:54.0000] still want to make a babel plugin for it tho [23:29:58.0000] or, ideally, have someone else do that [23:30:09.0000] ( [23:30:23.0000] "users" meaning end users, i.e. people who open websites, not people who design them [23:30:24.0000] ) [23:30:46.0000] yeah i don't think it improves much for websites [23:31:13.0000] but it pops up enough for me that i have revisited the idea once or twice :P [23:31:20.0000] make the plugin! [23:31:28.0000] i looked at that a few months ago actually [23:31:56.0000] i couldn't figure out how to test it or develop it [23:32:10.0000] should ask in the babel slack; they were pretty responsive, last I checked [23:32:25.0000] perhaps i'll take a look later [23:32:47.0000] i think the main problem is that i wouldn't bother with it if it was a babel plugin [23:32:52.0000] since i rarely ever use build tooling at all [23:32:53.0000] adding new syntax is a bit tricky; in some cases you can just extend the parser, but usually you'd have to actually add it to the parser and then the plugin just enables or disables the option [23:32:59.0000] mm, yeah [23:35:08.0000] i bet variable length encoding the codepoints could make the blob smaller, but that would make parsing take longer [23:58:32.0000] you could just start using build tooling [00:02:54.0000] hmm using finite state trees i get the map down to 200kb [00:03:29.0000] the data isn't searchable in place though [00:03:40.0000] at least not with the lib i'm testing [00:04:06.0000] and it assumes all the values are 64 bits, instead of 32 bits [00:04:42.0000] i'd imagine specializing for the data and keys we have it could be 200kb and also support lookups in place [13:34:03.0000] Hello! Can someone add me as a delegate so I can access the queue? [13:34:19.0000] cc akirose [13:35:40.0000] https://github.com/tc39/Admin-and-Business/issues/12 😝 [13:35:42.0000] on it [13:37:29.0000] Reopened issue with proper names :) [13:37:55.0000] JemYoung: done [13:38:03.0000] Thanks! 2019-12-04 [10:50:11.0000] /me hello! I think I should be joined properly now. [10:51:06.0000] tantek: you're here in the public channel :-) ping bterlson for an invite to the private one [10:51:22.0000] /me thanks ljharb! [12:41:45.0000] Hi everyone, I am new comer from UC Browser, Alibaba. Also new to the IRC tool. [12:47:27.0000] We’re (myself, Yulia, Shelley) stuck downstairs. Could anyone find someone to help us come up? [13:03:38.0000] bnb: wrong channel, but someone's on the way [13:03:40.0000] zuojian: welcome! [13:04:02.0000] Thank you - I was told to post it in all the channels 😅 [13:04:33.0000] lol then o7 [13:05:36.0000] haxjs: are you in the call? [13:22:10.0000] I had an idea for a possible class enum block syntax. Looking for a second opinion on this approach to enumerations. https://gist.github.com/metanomial/5cda898056970287b8b85424934bbddf?ts=4 [13:23:10.0000] metanomial: i replied to your discourse with links to two enum proposals; have you reviewed those? [13:23:23.0000] I did [13:23:43.0000] and how does your proposal differ from those? [13:44:40.0000] Both of those proposals are syntactic sugar to declare objects of constants. The second proposal was a little more flexible, allow enumerators to be passed to constructor functions before definition. The idea I linked above is syntactic sugar for quickly constructing static fields/instances in a class. I have updated my gist to show static [13:44:40.0000] instances in the current class syntax. [13:46:04.0000] metanomial: ok so it seems like yours is restricted to when you want your enums to be instances of the same class, which imo doesn't match many use cases for enums [13:46:27.0000] metanomial: iow to me, it doesn't seem like "sugar for static properties that are always instances of the class" is worth syntax [13:58:34.0000] I think I agree - that takes almost exactly as many characters to do in today's syntax, with `Color.RED = new Color(0xff0000);`/etc immediately following the class definition. [13:59:13.0000] And I agree that's not what many (/most?) of the calls for "enums" are asking for. [13:59:22.0000] and with class fields you can do `static RED = new Color(0xff0000)` [14:41:16.0000] Fair points. Here is a second example showing demo usage. https://gist.github.com/metanomial/5cda898056970287b8b85424934bbddf?ts=4#file-example2-js [14:49:09.0000] metanomial: So that looks like you're implementing a lot of useful enum functionality in userland; the enum itself is providing almost no additional benefit here besides moving the instance declarations around in the file. [14:49:44.0000] If we're doing enums, a lot of this stuff should be provided automatically, imo. [14:54:49.0000] Another fair point. I'll think on it a bit. Thank you for the feedback 2019-12-05 [16:56:26.0000] is there a specification anywhere for //# sourceURL=... ? [16:56:52.0000] jwalden: source maps might be in html, but def aren't in JS [16:56:52.0000] jwalden: it's a google doc [16:57:05.0000] do you still want it? [16:57:13.0000] michaelficarra: yeah, I could use it [16:57:42.0000] jwalden: https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit [16:57:44.0000] michaelficarra: it looks like Firefox just is not going to enforce *at all* //# sourceURL=... if it appears inside a function body, unless that function body is "use asm" or some other very obscure edge cases [16:57:58.0000] presumably most people just do it top-level and are fine, but [16:58:22.0000] inside eval [16:58:27.0000] jwalden: find "Linking generated code to source maps" in that doc [16:59:53.0000] devsnek: inside eval you have just a regular Script, so e.g. eval("function f() {\n//# sourceURL=https://example.com/foo.js\n}\nalert(new Error().stack);") would trigger what I'm talking about [17:00:11.0000] oh wow [17:04:06.0000] michaelficarra: what's supposed to happen if I have more than one //# sourceURL=... comment in a script? [17:04:19.0000] michaelficarra: does the last one apply, or the first one, or what? [17:04:37.0000] jwalden: I know *of* the spec, I am not an expert or the author [17:04:46.0000] bah :-) [17:05:03.0000] also, it's hard to call it a spec [17:05:19.0000] it's a loosely-written design doc [17:05:50.0000] yeah :-| [17:06:00.0000] SpiderMonkey appears to just apply the last one observed [17:09:46.0000] jwalden: if you know nick fitzgerald, you may be able to learn more [17:10:04.0000] :-) I could poke him for sure [17:11:05.0000] good luck [17:11:15.0000] this is of course not how specifications are supposed to work! [17:11:19.0000] /me cantankers [17:12:59.0000] jswalden: I've been trying to get the Sentry folks to adopt that doc and add some rigour [17:13:11.0000] they are heavy users of source maps and it would be in their interest that they work well [17:13:34.0000] CSP is an _actual_ spec and has similar problems [17:13:37.0000] if you learn of such an effort, let me know, I'm interested [17:14:11.0000] CSP doesn't count [17:14:28.0000] why not it should [17:23:00.0000] sadly, my suspicion is I ought not let myself get nerd-sniped by this, given I was looking into very different issues 2019-12-06 [13:24:12.0000] anyone know the historical reason for this? in 14.3.1 Static Semantics: Early Errors: "It is a Syntax Error if ContainsUseStrict of FunctionBody is true and IsSimpleParameterList of UniqueFormalParameters is false." (https://tc39.es/ecma262/#sec-method-definitions-static-semantics-early-errors) [13:24:12.0000] i.e. why (function() { return { method(...foo) { "use strict"; } } })() isn't valid [13:26:53.0000] rickbutton: parsing difficulties [13:27:21.0000] ah, gotcha, thx [13:27:33.0000] rickbutton: because otherwise the engine has to parse the entire arg list - which might include default args, which might themselves create functions that may or may not be in strict mode - before getting to the body's strict pragma, which then might mean it needs to interpret all that arg stuff differently [13:27:38.0000] that's my understanding, at least [13:28:08.0000] right, that makes sense [13:34:36.0000] Bakkot: btw that bug in chrome, it looks to be evaluating it without the side effect detection ebaled [13:34:39.0000] enabled* 2019-12-07 [18:38:16.0000] devsnek: huh. I wonder why [18:38:53.0000] Bakkot: weird devtools logic [18:39:06.0000] it looks like it doesn't enable it if it's just a member expression [18:39:11.0000] which is very odd [18:39:37.0000] and why I couldn't repro in my node thing 2019-12-09 [22:20:45.0000] devsnek, Bakkot: what's the Chrome DevTools bug? please file it if you haven't already, thanks [00:21:52.0000] mathiasbynens: reported already https://bugs.chromium.org/p/chromium/issues/detail?id=1031243 [00:24:40.0000] mathiasbynens: devtools seems to be doing a local parse of the input and using that to decide if it has side effects [00:25:14.0000] which seems counter intuitive to the existence of v8's side effect detection [01:34:45.0000] devsnek: agreed... we should just rely on V8 here instead of trying to "guess" with broken heuristics [01:35:34.0000] we're fixing it! thanks for pointing that out [11:37:40.0000] Can someone explain https://www.ecma-international.org/ecma-262/10.0/#sec-block-level-function-declarations-web-legacy-compatibility-semantics to me, please? In particular, I've got the following code: https://pastebin.com/Zx0VNUaj and I want to know where its behavior is specified [11:38:50.0000] it seems like it'd have to do with (3.) in that list, but it does say that "No other declaration of f that is not a var declaration occurs within the function code of g" - there is a `let bar = 3` which fails that condition [11:40:02.0000] avp the notes at the beginning of the section are just of historical interest - they're documenting cases where browsers agreed before this was specified in ES2015 [11:40:08.0000] the actual changes are in B.3.3.1 [11:40:21.0000] sidebar: you should use the living spec at https://tc39.es/ecma262/#sec-block-level-function-declarations-web-legacy-compatibility-semantics [11:41:06.0000] Bakkot: thanks, i'll try and use that section to reconcile my mental model [11:42:10.0000] B.3.3 is notoriously the most cursed section of the spec though [11:42:20.0000] so don't feel bad for being confused :p [11:43:34.0000] the basic semantics are: when you have `function f(){ x() }` within a block, and you could replace that with a `var f` without getting a syntax error, then the semantics of the function are 1) you add a `var f;` to the top of the _containing_ function, 2) you add a `let f = function(){ x() }` at the top of the containing _block_ and 2) when control reaches the actual function declaration within the block, you read from the `let f` and [11:43:35.0000] write to the `var f` [11:43:43.0000] ugh, that second 2) should be a 3) obviously [11:44:46.0000] Bakkot: that helps a lot - deciphering the intent of B.3.3.1 was daunting [11:57:20.0000] avp also you should use strict mode so this doesn't happen :P [12:01:55.0000] JSC has bugs for B.3.3 early errors that I've been too scared to fix [12:04:02.0000] everyone does [12:04:04.0000] the spec does [12:04:25.0000] https://github.com/tc39/ecma262/issues/913 etc [12:19:12.0000] it's functions all the way down [13:13:46.0000] > dysfunction all the way down [13:13:46.0000] FTFY [13:38:59.0000] Object.assign(Object.prototype,{get:()=>{}, set:(v)=>{}, value:undefined}); wrecks so much [13:39:22.0000] it kinda seems like you have to use null prototypes to guard against it [13:45:47.0000] bradleymeck: ? what key are you trying to defineProperty there? [13:49:01.0000] none, just if Object.prototype has all 3 of those keys Object.defineProperty stops working unless you use null prototypes like Object.defineProperty(obj, 'propname', {__proto__:null, value: 'value'}) [13:49:20.0000] since it sees stuff up the proto chain and says it can't be both an accessor and data prop [13:49:40.0000] was staring at my node pr and noticed we don't guard this currently [13:49:43.0000] ohhhhh wow i just realized what you mean [13:50:02.0000] i wonder if it'd be web compatible to change that somehow [13:50:29.0000] well idk but running that little script on all my open tabs killed all of them except some static sites [13:50:51.0000] likely we can't change it though [13:51:59.0000] we can't make it be own properties i'm sure, but i wonder if we could effectively make it be "Get" but stop before Object.prototype [13:52:16.0000] that seems pretty weird too [13:52:18.0000] better question [13:52:24.0000] who is doing Object.assign(Object.prototype,{get:()=>{}, set:(v)=>{}, value:undefined}) [13:52:52.0000] me, checking to see if we survive it in node (we don't) [13:53:15.0000] once you get implicit set hooks things look pretty dicey about data exfiltration across modules [13:53:32.0000] but 🤷 this is more just locking down stuff to survive craziness [13:53:57.0000] we had a couple of people snooping internals and doing bad things in the long past and we started to move to primordials in part because of that [13:54:56.0000] i remember symbol polyfills were able to patch node [13:55:08.0000] so that util.inspect and stuff worked with them [13:55:52.0000] causing it to always error by filling out both get/set always or value is probably good enough honestly [13:56:39.0000] ideally we would use some null proto shenanigans but slowdown on benchmarks is pretty bad [13:57:47.0000] i just don't see why its worth guarding against [13:57:53.0000] bradleymeck: another alternative is that the error for "no get/set + value" could be made to only throw when get/set is not undefined, instead of just present [13:58:13.0000] bradleymeck: that way you'd always be able to locally override the shenanigans with `get: undefined, set: undefined` for data properties [13:58:25.0000] altho i guess that wouldn't protect you for accessors [13:58:46.0000] devsnek: same thing as why any other part of the runtime is worth being robust [13:59:12.0000] i don't really get the overall goal tbh [14:00:18.0000] user code shouldn't be able to break the platform? [14:00:57.0000] mostly its to get reliable behavior when things go wrong, node has access to things like shell execution and often people send authorization strings to node in various ways, you don't want people snooping on strings and you don't want shell execution to happen. it gets hard to understand what a user can accidently load (see all those malicious packages people install) and have it undermine the default platform APIs [14:01:40.0000] malicious code can just `require('inspector')` and read every value of every variable in the entire codebase [14:01:49.0000] so, make it just ignore anything strange and/or make it survive anything strange to avoid leaking data or allow accidental execution. accidental execution is hard to avoid in JS [14:02:07.0000] devsnek: not if you use a policy that doesn't allow it [14:02:17.0000] which is why we have started making efforts to use em [14:02:51.0000] assuming the code you've explicitly pulled in is malicious is like [14:03:11.0000] you've already lost [14:03:21.0000] you either need full isolation [14:03:25.0000] devsnek: we work with developers who install 3rd party code all the time. you build up layers of defenses like anything else [14:03:25.0000] or you need to trust the code somehow [14:03:43.0000] even with full isolation you can get confusion problems that make the isolated payload malicious [14:04:08.0000] seems like an inherently losing battle tbh [14:04:42.0000] devsnek: the entire concept of SES is winning that battle, isn't it? [14:04:46.0000] or attempting to [14:05:00.0000] 🤷🏻 [14:05:08.0000] i think security always will be a race of sorts yea. though i don't think we are really trying to prevent everything, but instead make auditing feasible [14:05:20.0000] i think SES solves a symptom of the problem [14:05:22.0000] not the problem [14:05:48.0000] even reading code line by line myself i'm not fully confident in it not having some odd effect (i had one with a sticky regexp today!) [14:06:09.0000] bradleymeck: wait you had a real use case for the sticky flag?? [14:06:22.0000] ljharb: i saw it being used and i removed it [14:06:30.0000] cause lastIndex was being weird with .search [14:06:55.0000] anyways, i do want to use shell commands so it isn't like i can ever really trust anything [14:08:19.0000] aha [14:08:55.0000] ljharb: the idea was to match the last " in a quoted string but it wasn't working right [14:09:23.0000] misplaced sticky flags won't exfiltrate your tokens [14:10:16.0000] devsnek: no, but it did change a parser and we got bad data that bypassed some checks! [14:15:30.0000] you can always keep structured data structured... bugs exist of course but these systems aren't inherently fallible [14:20:01.0000] devsnek: not all data is provided to you in a structured format; you can't get away from parsing untrusted input sometimes [14:20:36.0000] even if it is structured it can be bad to intake naively ("__proto__" from json payloads) [14:20:54.0000] I mean the output of the parser [14:21:15.0000] it's still the output of the parser, and you can know it may be unsafe 2019-12-11 [23:52:19.0000] if we get tuples in js, advent of code will become a lot easier, because a lot of their challenges use maps of (x, y) [07:12:49.0000] devsnek: why not use literals for those? [07:13:16.0000] new Map([[x,y],[a,b]]) is often forgotten too :( [09:45:47.0000] It is pretty easy to write an n-key map class [09:57:46.0000] Bakkot: it could be easier [09:57:57.0000] sure but you do it once and then it is done [09:58:53.0000] depends on if the base class adds apis [09:59:00.0000] if it adds apis you do it again [09:59:30.0000] if it adds APIs your map will not automatically update to have those APIs, yes [09:59:39.0000] (depending on how they are implemented...) [09:59:40.0000] but no existing applications will break [09:59:48.0000] yup [10:00:25.0000] even if they are implemented through delegating to existing interfaces it might be odd [10:00:37.0000] Potentially yes [10:00:50.0000] like .has could be false but .get could return a value if we add default values that are not undefined [10:00:50.0000] also when I've done this in the past I haven't actually done `extends Map` [10:00:57.0000] interesting [10:01:14.0000] (since it doesn't really keep the interface for map) [12:22:01.0000] bradleymeck: you need identity of the x and y [12:22:22.0000] (x, y) === (x, y) [12:22:24.0000] Symbol.compositeKey would be nice~ [12:22:29.0000] yeah [12:22:38.0000] I guess there's also that frozen proposal [12:22:41.0000] that probably won't go anywhere fast though :( [12:22:48.0000] mine/compositeKey [12:22:59.0000] value types seem to have some momentum [12:25:07.0000] I just hope they allow all types inside [12:34:38.0000] i'd not be ok with that unless they change intent of the proposal a bit [12:34:47.0000] though if they do change stated intent seems doable [12:37:22.0000] it seems kinda useless if it can't hold objects tbh [12:37:50.0000] like private fields, I'd use them every once in a blue moon but not as a generalized pattern [12:39:08.0000] if serializable and stateless is the critical use case holding objects would be problematic. if immutable but allowing state is the critical use case holding refs seems fine. [12:39:35.0000] you can have them without objects inside them even if objects are allowed [12:39:54.0000] and even then, think of JSON.serialize on an object with a function property [12:40:03.0000] er [12:40:07.0000] JSON.stringify [12:40:27.0000] ? [12:42:22.0000] I don't get why one person wanting to restrict it means another person can't also use it more liberally [12:43:09.0000] depends, but if the more liberal use makes it hard to assert the more constrained use holds true in various cases thats usually a reason [12:43:41.0000] I mean it's a trade off either way [12:43:55.0000] the more constrained case literally makes it impossible for the more liberal use case [12:44:09.0000] yea, like you said its a trade off [12:46:10.0000] I feel like the obvious balance would be choosing the difficult case over the impossible case [12:46:23.0000] but people consistently go the other way so 🤷 [12:47:31.0000] difficult enough to be impossible pretty much is just impossible [12:50:26.0000] if it's an invariant of serialisation you can throw when you hit an object [12:50:34.0000] it doesn't seem too hard imo [12:56:58.0000] devsnek: the reason to disallow objects is that many people are going to look at these things and assume they can treat all of them as immutable and be bitten when that turns out to not be the case [12:57:37.0000] I didn't have that assumption [12:57:59.0000] many other people will [12:58:53.0000] a lot of people also assume const makes the object it holds immutable [12:59:06.0000] like probably at least one a week in ##javascript [12:59:25.0000] should const have not been allowed to point to objects? [13:00:04.0000] I am not entirely clear on why const exists at all, in honesty [13:01:17.0000] variables that can't change [13:01:51.0000] that is a description of the thing, not an explanation of why it exists [13:02:00.0000] const is great, but it is definitely a confusing name [13:02:15.0000] I mean I use it as that enough to justify it as the sole reason for it's existence [13:02:22.0000] I dunno if others do [13:02:37.0000] (i like it because it conveys developer intent to not reassign a variable, which is not sufficiently conveyed by "it doesn't happen to be reassigned at the moment") [13:03:17.0000] in any case my larger point was that no matter what, there will be people who don't understand features because they assume their behaviour instead of actually learning what they do [13:03:52.0000] of course, and that's something we always have to weigh [13:04:01.0000] here I think most people will assume it is deeply immutable [13:05:18.0000] maybe we can make a poll or something [13:07:58.0000] the name itself is definitely bad, but I don't understand folks not taking the time to get used to it [13:08:37.0000] we could just remove the immutability part from them [13:08:43.0000] :P [13:10:00.0000] like, it seems that there are folks that advocate for using `let` and not `const` because `let` itself might've been a better name for what `const` does, but [13:10:49.0000] that's really upsetting to me since at the end of the day, `const`'s behavior is exactly the desirable thing, and the name can be gotten used to... [13:10:50.0000] var was already taken though [13:10:56.0000] yeah that's the thing [13:11:07.0000] I love Scala's `val` / `var` [13:11:18.0000] yeah val's not bad [13:13:24.0000] something I'm a little unclear of the timeline on is the existence of a `const` keyword in browsers [13:13:45.0000] I feel like it existed non-functionally prior to ES6? [13:14:09.0000] but maybe that's some headcanon of mine that developed due to the long implementation window of ES6 [13:14:24.0000] rkirsling: old spidermonkey had its own const and let for awhile [13:14:29.0000] that had different semantics from ES2015's [13:14:34.0000] eventually they fixed it [13:14:36.0000] that must be it [13:14:49.0000] in their "JavaScript 1.7" thing, or whichever version [13:14:56.0000] ahh [13:15:15.0000] old V8 also had it's own let and const [13:15:15.0000] with weird semantics [13:15:15.0000] they weren't allowed in strict mode [13:16:08.0000] ah right that too [13:16:21.0000] i think v8's tho were early ES6 versions [13:16:36.0000] altho maybe SM's were even earlier ones, i dunno [13:17:13.0000] I'm glad node doesn't use harmony flags anymore [13:17:15.0000] lots of breakage [14:00:04.0000] do we have a strong assertion about run to completion semantics in JS written out anywhere/what to do if a host implements a co-routine like Job Scheduler? [14:09:14.0000] e.g. if a host is allowed to have `Promise.resolve().then(()=>{...;bar();...}); foo();` execute `bar()` before `foo()` [14:10:47.0000] if that isn't explicitly forbidden than ES6 has a massive gap [14:11:11.0000] i'm pretty sure it was a quite intentional part of promises that nothing that happens in a then callback can *ever* happen synchronously [14:11:45.0000] TLA changes that slightly, in that if you `await` that promise before calling `foo()`, then bar can happen before foo [14:13:40.0000] ljharb: i'm staring at https://github.com/nodejs/node/pull/30891 [14:14:24.0000] bradleymeck: i mean, `require()` can already "sleep" if the module wants it too [14:14:27.0000] bradleymeck: via node addons [14:14:49.0000] ljharb: thats different though. that PR lets you unwind promises [14:14:55.0000] oh right true [14:14:59.0000] sleep/atomics is fine [14:15:29.0000] even execSync is probably fine since it isn't using exposed machinery even though it does nest JS [14:17:37.0000] but JS that can't share an env [14:22:49.0000] it kind of does due to the streams impl [14:22:56.0000] but not from the process [14:23:10.0000] it just inlines an event loop to resolve streams events [14:23:21.0000] which aren't under the promise-like invariants [14:24:55.0000] that isn't really exposing that stuff to userland though so 🤷 [14:53:55.0000] bradleymeck: it could never execute the inner bit first [14:54:14.0000] the only thing possible is if foo pumped the event loop, it would happen *during* [14:54:19.0000] but never *before* [14:54:45.0000] actually [14:54:53.0000] I don't know if foo pumping the event loop is allowed [14:54:56.0000] I hope it isn't [14:55:00.0000] i'm not clear on that, if you require out of the inner loop and grab the outer promise and await it [14:55:12.0000] it looks like it would resolve [14:55:38.0000] /me thinks this is esoteric [14:56:26.0000] I think it's safe to assume nothing will ever do that [14:57:44.0000] i never thought modules would delete themselves from require.cache at one point, but they do [14:58:11.0000] i can imagine finding an easier way to do this kind of forced resolve being possible but not obvious 2019-12-12 [20:31:02.0000] ljharb: is `ChainEvaluation` supposed to link to the runtime semantic? [20:31:42.0000] devsnek: um, i'm not sure. which PR was this in and can you link me to the rendered spec? [20:31:52.0000] devsnek: linking generally is handled by ecmarkup [20:31:58.0000] https://tc39.es/ecma262/#sec-optional-chaining-evaluation [20:32:07.0000] `Return the result of performing ChainEvaluation of ...` [20:32:12.0000] ChainEvaluation there doesn't link [20:32:41.0000] i don't think any grammar things link there [20:32:48.0000] see https://tc39.es/ecma262/#sec-runtime-semantics-arrayaccumulation for example [20:33:31.0000] (by "link there", i mean, i don't think that category of thing is autolinked in general terms) [20:33:39.0000] ic [20:33:40.0000] unfortunate [20:33:49.0000] also in ChainEvaluation [20:34:05.0000] please file an ecmarkup bug if you think they should autolink tho :-) [20:34:07.0000] there are productions like `OptionalChain : OptionalChain arguments` [20:34:14.0000] and then it says "evaluate OptionalChain" [20:34:33.0000] like i know it is referring to the second one [20:34:38.0000] but it isn't immediately obvious [20:35:31.0000] an editorial PR would be helpful :-D [20:35:51.0000] not trying to pass the buck every time, just about to head out and can't track it myself rn [20:36:25.0000] np [20:40:04.0000] I think those are ecmarkup concerns [20:41:24.0000] cause in particular ChainEvaluation(...) was changed to ChainEvaluation of ... to align with current editorial practices but that incurred a loss of linkability [20:42:22.0000] er sorry the latter is separate [20:43:24.0000] that we had to fix because there's a very specific was the spec differentiates parent nonterminal Foo from child nonterminal Foo [20:44:08.0000] it is meant to be as intuitive as one could reasonably hope for but if you can think of a way to describe it in a Notations section that might be cool [20:44:51.0000] optional chaining and nullish coalescing unflagged in engine262 🎉 [20:44:52.0000] *...very specific way... [20:45:14.0000] 🎉 [20:45:17.0000] this one is my favourite though https://github.com/engine262/engine262/commit/7e7692de0050c5149f0dfd553c67bdb565b1174c [20:45:53.0000] nice [20:46:02.0000] would be nice if we had like `OptionalChain_a` and `OptionalChain_b` [20:46:39.0000] reminds me of https://trac.webkit.org/changeset/240686/webkit [20:46:57.0000] lol [20:47:41.0000] Yeah _a and _b could be reasonable [20:48:01.0000] In general, a syntax-directed operation will be defined in many clauses, so what would you auto-link to? [20:48:18.0000] the general heading [20:48:31.0000] https://tc39.es/ecma262/#sec-optional-chaining-chain-evaluation [20:48:53.0000] yes, for that case there's only one clause, but in general there might be several. [20:51:24.0000] wdym there are like six there [20:51:52.0000] "clause" = section, say [20:52:53.0000] the spec doesn't really have a word for the construct that there's six of, but I'd call them 'definitions' [20:58:45.0000] or emu-grammar+emu-alg pair, if I need to be explicit [23:05:18.0000] I think sometimes eval rules paired with parse nodes / productions are referred to as reducers (not in the spec, just seen it elsewhere) [23:14:01.0000] does anyone know what production accepts the strings '\8' and '\9' in sloppy mode? Chrome and FF both allow them (treated as identity escapes), but I’m having trouble finding an avenue that explains it. possibly this is a spec/web reality divergence, but I feel like I’m just missing something since it’s easy to get confused when looking at annex b modifications. [23:31:09.0000] Oh, they allow \8 and \9 in strict mode too o: [23:38:59.0000] here’s my notes from trying to figure this out as a gh gist to avoid making too much noise in here: https://gist.github.com/bathos/09171830ee14d3d7a0d9393eb07f64ca [06:18:21.0000] looks like test262 only has \8 in regex literals. [06:19:21.0000] but test262-parser-tests has 2 occurrences, and they're both under fail/ [07:10:30.0000] (bathos ^) [07:31:59.0000] thanks — I take it that confirms the interpretation that \8 and \9 being permitted as identity escapes in Chrome/FF is off-spec [10:59:57.0000] it's possible test262-parser-tests is wrong; I tried to be accurate with all of them but I do not have access to any way of formally verifying their correctness [11:04:03.0000] ah. well, we came to the same conclusion, anyway, which seems like a data point. [11:04:10.0000] though this came up a while ago and I think the logic in this comment is still correct: https://github.com/jquery/esprima/issues/1502#issuecomment-230672053 [11:06:47.0000] yeah, that’s pretty much 1:1 with what I wrote in the gist link when trying to find all the paths [11:13:49.0000] should probably open an ecma262 issue if there isn't one already [11:14:30.0000] I think this was lost in the move from the old bug tracker: https://web.archive.org/web/20141214073322/https://bugs.ecmascript.org/show_bug.cgi?id=1553#c2 [11:14:35.0000] also https://mail.mozilla.org/pipermail/es-discuss/2013-March/029403.html [11:15:03.0000] https://github.com/whatwg/javascript/issues/12 [11:15:07.0000] etc [11:23:21.0000] does anyone know if js shift is going to track 2019 and 2020 updates [11:32:05.0000] yes, once we have time [11:32:17.0000] assuming you mean https://shift-ast.org/index.html [11:33:04.0000] ast spec for 2019 is done; ast spec for 2020 will get made once es2020 is done [11:57:15.0000] I'm looking for parsers to vendor into engine262 [11:57:30.0000] shift looks the best so far but not updated since 2018 [11:57:41.0000] I could probably help out with updating it [12:00:23.0000] what does "vendor" mean when used as a verb? [12:00:37.0000] jmdyck: copy into my repo [12:00:49.0000] tx [12:01:29.0000] I'm really not enjoying the "extend acorn" approach I currently use [13:09:40.0000] devsnek: it should be pretty easy to update; there were very few syntax changes in 2019 [13:09:57.0000] happy to help with that if you actually want to try 2019-12-13 [10:40:38.0000] https://tc39.es/ecma262/#sec-numberbitwiseop seems a bit circular [10:40:42.0000] step 3, i mean [10:42:16.0000] & is specified in terms of Number::bitwiseAND which is specified in terms of & [10:42:59.0000] "applying the bitwise operator op" tho isn't the same as how `&` is specified, is it? [10:43:16.0000] What does that phrase mean? [10:43:49.0000] perhaps we're missing an explicit definition for it - but the intention i think is to do math [10:44:17.0000] yeah, i think that has to be the intention, [10:45:02.0000] ie if the op is &, it should do what previous editions did here: http://www.ecma-international.org/ecma-262/#sec-unsigned-right-shift-operator [10:45:13.0000] where it just says "compute rnum & 0x1F" [10:45:44.0000]