2021-04-01 [19:39:50.0000] another april fools gone by that we haven't rebranded to typescript [19:42:15.0000] april fools is not gone by as yet :) [20:01:29.0000] bakkot_: maybe this https://bugs.ruby-lang.org/issues/17768 [21:44:16.0000] i mean, not the worst proposal tbh [12:35:04.0000] ptomato: thanks for the heads up 2021-04-03 [20:43:50.0000] I have a question [20:44:04.0000] me too [20:44:29.0000] The exported binding (`export let a = 1`) of a module has the object descriptor `writable: true, value: 1` [20:45:14.0000] but if you try to write to it `"use strict"; mod.a = 2` you will get an error `TypeError: Cannot assign to read only property 'a' of object '[object Module]'` [20:45:49.0000] this behavior cannot be simulated with user land code [20:48:06.0000] oh [20:48:11.0000] I can do it with a proxy [20:48:13.0000] never mind [21:02:58.0000] I'm wondering why there isn't an ArrowFunction() constructor. Is it just that no-one wants it, or is it logically incoherent in some way? [21:21:41.0000] jmdyck: no idea what the history is, but I do note that there is an ambiguity about which kind of body to use [21:26:29.0000] Well, there wouldn't have to be: you could just say that the body arg is parsed as a ConciseBody. But that would be inconsistent with the existing function constructors, which implicitly 'wrap' the body arg in braces. [21:40:25.0000] right; you can break the ambiguity by making an arbitrary choice, but it's not something which naturally follows [21:43:51.0000] are `new realm.Compartment` and `new compartment.Realm` leads to the same sandbox? šŸ¤” [00:55:41.0000] does this place also server as a channel for talking about ecmascript, or is it more specifically for conversations about the specification? are there other channels for more light-hearted discussion about things we're doing and such? [09:56:21.0000] aradesh it does also serve as a channel for talking about ES, yes [10:11:59.0000] cool. i'm writing an ES parser in python for fun. [10:12:26.0000] using the specification document as my guidance 2021-04-04 [08:17:59.0000] jmdyck branch of ecmarkup for 545: https://github.com/tc39/ecmarkup/tree/structured-header [08:18:07.0000] the readme has usage and so on [08:18:32.0000] if you don't have npm I can push a commit to your branch to make use of it [14:51:57.0000] Bakkot: thanks. I imagine you should push that commit regardless of whether I have npm. [14:52:56.0000] sure, done [15:13:35.0000] my python ES parser is slowly coming along. making lots of funny tests: https://i.imgur.com/6enAi3o.png [15:16:18.0000] aradesh if you are interested in outside-the-spec material, https://github.com/mozilla-spidermonkey/jsparagus/blob/master/js-quirks.md is a good document for anyone writing a new parser for ES [15:18:05.0000] thanks [15:20:06.0000] conclusion: Do not write a JS parser. [15:20:09.0000] uh oh 2021-04-05 [18:08:25.0000] Bakkot: I'm getting the spec into the format that ecmarkup wants [18:11:27.0000] I thought it was going to be tricky, because the info that used to all be in a
is now spread over +

+
[18:11:58.0000] but I was able to hack something together. [18:15:34.0000] sweet [18:15:44.0000] yeah, when I was playing with it the fact that they're adjacent made it easier to deal with [18:19:12.0000] I'll commit when I've got something that's basically correct, and then we can iterate. [18:19:20.0000] sgtm [18:19:26.0000] that's what I did with ecmarkup [18:36:41.0000] btw, I don't like the term "concrete method". (It suggests they're more concrete than "abstract operations".) So I'd like if we could change that before too much gets built on `type="concrete method"`. [18:43:29.0000] honestly just "method" seems like it would work fine [18:43:36.0000] possibly "abstract method" [18:44:39.0000] though I guess "abstract" is awkward there because it's confused with the use of "abstract" as in the Java keyword [18:49:02.0000] just "method" could be confused with in-language method. [18:49:17.0000] I suggest "record method" [18:49:29.0000] (until "record" gets renamed) [18:51:24.0000] hmm [18:51:44.0000] that would maybe work [18:51:58.0000] "specification method", alternatively, if we want to be explicit about it [18:54:55.0000] "specification method" is a little too general, because we've also got internal methods [18:55:06.0000] and numeric methods [18:58:15.0000] mm, true [18:58:19.0000] I was going off of "The Environment Record abstract class includes the abstract specification methods defined in Table 17." [18:58:40.0000] "record method" is probably the way to go [18:58:47.0000] want to open an issue about it or shall I? [18:59:55.0000] maybe you, i've already got lots of issues. [19:02:45.0000] side benefit: this frees up "concrete" for other use. E.g. "ECMAScript language value" -> "concrete value" [19:04:00.0000] opened https://github.com/tc39/ecma262/issues/2371 [19:08:00.0000] tx [19:14:38.0000] ok, finished skimming the diffs [19:20:26.0000] committed and pushed! [19:27:12.0000] wait, did that overwrite your push Bakkot? [19:27:27.0000] it did, I can re-do [19:28:36.0000] I should fetch that and rebase (or something) [19:31:42.0000] anyway, it's looking pretty decent at a glance [19:32:21.0000] couple of things which stand out so far: the algorithms in https://tc39.es/ecma262/#sec-properties-of-valid-executions aren't handled right by ecmarkup [19:32:27.0000] since they're weird [19:33:39.0000] also, GetGeneratorKind (and presumably other AOs which take no arguments) isn't handled - in the particular case of AOs with no arguments it's probably worth leaving it on a single line [19:34:43.0000] note for later: StringToBigInt, FunctionDeclarationInstantiation, GetWaiterList have moved-paragraph diffs [19:35:57.0000] oh, also, ecmarkup isn't inserting the "It" in the "description" field [19:36:49.0000] afk a while [19:36:50.0000] that was intentional; especially for the multi-sentence ones, it's annoying to have to remember that the first sentence is truncated at the start [20:09:24.0000] oh the GetGeneratorKind thing is actually just a bug in ecmarkup. still, those should be single-line probably [20:28:39.0000] Bakkot: re empty param list: will ecmarkup know to look for the dl is the h1 isn't multi-line? [20:29:34.0000] s/is/if/ [20:30:22.0000] yeah [20:31:23.0000] jmdyck LocalTZA is implementation-defined, not host-defined [20:31:28.0000] they're different things [20:31:42.0000] ah, 545 predates that distinction. [20:32:42.0000] wait, for no-params, do you want whole h1 on one line, or tags on separate lines? [20:33:10.0000] whole thing on 1 line [20:33:25.0000] identical to the pre-545 way of writing it [20:33:33.0000] k [20:33:55.0000] also: you've left "It performs the following steps when called:" in the description for `sec-moduleevaluation`, somehow [20:34:08.0000] possibly for all the concrete methods actually [20:34:32.0000] or, no, just Evaluate and Link so far, not all of them [20:34:58.0000] that sounds familiar, but i don't recall why it happened. [20:35:21.0000] do i need the package-lock.json change? [20:35:46.0000] i must need the package.json change. [20:36:42.0000] actually, maybe the package-lock change is old [20:37:03.0000] you can probably get away with skipping the package-lock change [20:37:19.0000] it does have a relevant thing, which is the change to the `ecmarkup` section of it, but it also updates other stuff whenever you install anything [20:38:09.0000] hey neat! this approach fixes a human error: https://tc39.es/ecma262/#sec-integer-indexed-exotic-objects-delete-p has "takes arguments" despite taking only one argument [20:38:38.0000] there's a few bugs in my ecmarkup branch which I am slowly working through [20:38:52.0000] with them fixed, the diff in the HTML is very small [20:39:32.0000] whee [20:40:00.0000] have rebased to the upstream, so presumably i won't overwrite your commit again [20:40:41.0000] Okay, so for the subject-less sentence, you'd like just "It" ? [20:43:43.0000] As opposed to (say) "This operation/method" [20:46:26.0000] Hm, the auto-rendering doesn't seem to be working. [20:52:05.0000] "It", yes [20:52:13.0000] k [20:52:16.0000] that's by far the majority [20:53:02.0000] re: auto-rendering: not sure what's up with that. might be the merge conflicts? [20:53:24.0000] I'll host a copy once I get ecmarkup fixed up [20:53:32.0000] I don't know what I can do about merge conflicts. [20:54:28.0000] My local master is same as upstream/master, and that's what I'm generating 545 from. [20:55:32.0000] I guess it doesn't like the 'history'? [20:55:57.0000] yeah, that's pretty odd. did you rebase on master? [21:04:18.0000] ok, pushed update. [21:04:38.0000] added "It" and single-line

for no-params [21:05:05.0000] yay, conflicts went away. [21:06:53.0000] (agreed re weirdness of Properties of Valid Executions) [21:07:57.0000] preview failed - I guess it doesn't like the "installing from branch" thing :( [21:08:34.0000] hrmph [21:13:16.0000] hosted a copy at https://bakkot.github.io/ecma262-previews/structured-header/ [21:17:10.0000] also posted the diff as a comment on the PR [21:17:26.0000] or, well, am attempting to post? github maybe does not like my comment with the whole diff in it [21:18:28.0000] got LocalTZA fixed locally [21:18:38.0000] ugh, and it doesn't support .diff or .patch files. that's dumb [21:25:45.0000] figured out the problem with Link and Evaluate [21:29:05.0000] okay, pushed up fixes. [21:30:18.0000] I think that's all you asked for? [21:32:58.0000] should also drop the custom styling from your branch, I guess [21:34:11.0000] Done. [21:37:13.0000] oh, also, why did you drop the "Static Semantics: " before ParsePattern? [21:37:46.0000] hmm [21:39:27.0000] So you want "

\n Static Semantics: ParsePattern (\n ..." ? [21:40:10.0000] I think so; that's pretty much what's there currently, just with linebreaks + types [21:40:18.0000] (ditto ParseText, of course) [21:42:13.0000] The code that analyzes headings doesn't retain "Static Semantics" or "Runtime Semantics". [21:42:22.0000] still gotta figure out what to do about the Races (etc) AO-like things and Abstract Equality [21:42:33.0000] hm, ok [21:42:37.0000] I think we can just drop it [21:43:04.0000] would want to do that as a different commit or PR, though [21:43:07.0000] one of several such [21:46:14.0000] I could hack it in if you like [21:46:37.0000] nah [21:46:40.0000] k [21:47:18.0000] at least, not yet; if the other editors really want to keep it around then it'll need to end up in the output somehow [21:47:33.0000] but don't bother unless and until that proves to be the case [21:55:15.0000] oh, and the "WeakRef emptying thing" isn't really an AO [21:55:21.0000] it probably does not need a header [21:56:01.0000] oh, also, you've stripped the return types from the descriptions, when they are present; I think we should leave them as-is for now [22:00:19.0000] ah, right. [22:02:14.0000] and we should figure out how to handle multi-paragraph descriptions, as in sec-resolveexport [22:02:22.0000] don't think we want to make them all one line [22:03:25.0000] I think probably just keep the `

`s, and ecmarkup will know to keep them in their own paragraphs if the `description` DT contains elements without any surrounding text [22:03:25.0000] I think i retain multi-paragraphs up to that point, so could make a bunch of

elements. [22:03:41.0000] yeah, sounds good [22:03:53.0000] only in the case that the description is multi-paragraph to start, though [22:04:01.0000] not in the typical case, where the description is inline [22:04:04.0000] yup [22:17:34.0000] pushed multi-paras. ResolveExport was the only one though [22:22:19.0000] I think it maybe makes sense to rephrase the preamble of GetWaiterList so that the description comes between the "The abstract operation GetWaiterList" part and the "It performs the following steps when called:" part [22:22:33.0000] maybe not though [22:22:53.0000] possibly that text belongs in its own section, actually [22:28:38.0000] WaiterLists appear outside that clause, so it would make sense for them to be defined outside that clause [22:32:30.0000] I think the WeakRef emptying thing should be made a proper AO. [22:35:35.0000] getting late here, heading off. [07:22:57.0000] Bakkot: I just pushed a version that preserves "returns" phrasing in descriptions. [08:44:27.0000] Is there any particular reason why `BigInt`s donā€™t work with `Math.sign`? [08:47:12.0000] jschoi: the bigint proposal sadly opted not to update the Math methods to work with bigints. i'd love to help with a proposal to do so. [08:48:48.0000] ljharb: Ah, that sounds great. If I get around to writing a proposal, Iā€™ll prod you. I ran into this while sorting an array of them. [08:49:29.0000] I wonder what the history behind that decision was. [08:52:51.0000] jschoi: iirc, it was more a desire to keep the proposal minimal [08:53:31.0000] Makes sense. [11:26:17.0000] > A conversion from a Number or BigInt x to a mathematical value is denoted as "the mathematical value of x", or ā„(x). [11:26:47.0000] does anyone know if there is a builtin function that would help me accomplish the above? [11:31:31.0000] DerekNonGeneric: there is none, because there's no concept of a mathematical value in observable JS [11:31:44.0000] DerekNonGeneric: what's the use case? [11:33:22.0000] ljharb, the algorithm for `isIntegralNumber` https://tc39.es/ecma262/#sec-isintegralnumber [11:35:17.0000] ljharb, do I need to unwrap boxed primitives using `Number.prototype.valueOf()`? [11:40:14.0000] DerekNonGeneric: yes. https://npmjs.com/unbox-primitive [11:40:35.0000] DerekNonGeneric: also, https://npmjs.com/es-abstract [11:40:48.0000] DerekNonGeneric: that way you don't have to reimplement abstract operations yourself :-p [11:42:52.0000] ljharb, it seems like you're missing this one [11:43:14.0000] DerekNonGeneric: because it's renamed in ES2021, and es-abstract only has ES2020 so far [11:43:46.0000] wow, this is huge [11:43:50.0000] DerekNonGeneric: you can use https://262.ecma-international.org/11.0/#sec-isinteger, it's the same operation [11:44:14.0000] DerekNonGeneric: it's what all my es-shims ecosystem polyfills use under the hood [11:44:49.0000] DerekNonGeneric: the part that's evaluated is small if you import, eg, `es-abstract/2020/IsInteger` [11:46:58.0000] interestingly #sec-isinteger makes no mention of making a "mathematical value" conversion [11:47:37.0000] all that stuff was added in ES2021 to improve the precision of the spec [11:47:43.0000] but to observable JS it's identical [11:48:20.0000] super confusing :p [11:50:14.0000] i don't think most people are trying to implement the AOs in JS :-p [12:06:07.0000] ljharb, it doesn't seem like `unbox-primitive` will work in my situation since at this point in the algorithm, it is still unknown whether the primitive is boxed or not [12:09:12.0000] ljharb, do you have a `maybe-unbox-primitive`? ^^ [12:29:07.0000] function maybeUnboxNumber(value) { [12:29:07.0000] return isNumberObject(value) ? numberValueOf(value) : value; [12:29:07.0000] } [12:36:16.0000] DerekNonGeneric: you could check it with https://www.npmjs.com/package/which-boxed-primitive first, i suppose [12:36:41.0000] DerekNonGeneric: i have an "is" predicate for every type already, so you could certainly use https://www.npmjs.com/package/is-number-object as a gate [13:07:14.0000] ljharb, my `isNumberObject` looks quite different from yours, but it appears that you have a bug in yours unless i misunderstood what yours in supped to do.. seems like you have may done the `typeof value === 'number'` check prior to doing the `typeof value === 'object'` check, would result in both primitives _and_ boxed primitives passing the check early [13:21:35.0000] DerekNonGeneric: yeah is-number-object is meant to do that, it's a misleading package name [13:21:48.0000] DerekNonGeneric: sadly someone claimed "is-number" which just does `isFinite()` [13:22:03.0000] DerekNonGeneric: all my primitive predicates return true if it has the internal slots, whether it's boxed or not [13:32:42.0000] ljharb, mine also currently checks the `[[Class]]` internal slot, but what is the purpose of `tryNumberObject`in yours? lol never seen that before [13:34:07.0000] ohh, you have put that part it in a try/catch block... I see now [13:52:35.0000] that is a very quite a unique way of going about doing this from what I have seen elsewhere (extremely defensive coding) [14:04:20.0000] DerekNonGeneric: the [[Class]] internal slot doesn't exist in ES6+, and Object.prototype.toString is not reliable in ES6+. [14:04:52.0000] i do code my leaf modules particularly defensively, that way i don't have to worry about those being the cause of breakage in any env [14:56:13.0000] > the [[Class]] internal slot doesn't exist in ES6+, and Object.prototype.toString is not reliable in ES6+. [14:57:06.0000] sorry, meant to say that i was still using `Object.prototype.toString` (still haven't migrated to anything more reliable yet) [14:57:09.0000] right [14:57:25.0000] DerekNonGeneric: feel free to use all my predicates in https://npmjs.com/~inspect-js, they're all as reliable as is possible [15:02:55.0000] ljharb, looking forward to it, but still haven't figured out the pros/cons btwx using that and the runtime typechecking solution Bakkot mentioned a couple weeks ago (ensure `Map.prototype.has.call(thing)` does not throw) [15:03:50.0000] DerekNonGeneric: if https://npmjs.com/is-map is true, it won't throw [15:19:02.0000] ljharb, any idea why `Map.prototype.has.call(thing)` even works at all? Also, are you doing this in `is-map` as well? [15:19:59.0000] DerekNonGeneric: yes, i am doing it in is-map. it works because the function checks the receiver for Map's internal slots. if it has them, it returns true or false, if it doesn't, it throws. so is-map try/catches around that [15:24:32.0000] that sounds much more reliable than what i have been using (only have a vague idea of what internal slots are and wonder if they are immutable) [15:34:16.0000] > Internal slots correspond to internal state that is associated with objects and used by various ECMAScript specification algorithms. Internal slots are not object properties and they are not inherited. [15:51:10.0000] DerekNonGeneric: the whole point of making those packages is so consumers don't have to think about it :-) [16:20:10.0000] > The value of the [[DataView]] internal slot is not used within this specification. The simple presence of that internal slot is used within the specification to identify objects created using the DataView constructor. [16:20:26.0000] > -- https://tc39.es/ecma262/#sec-properties-of-dataview-instances [16:22:30.0000] DerekNonGeneric: i haven't made an isDataView package, but i could if you need one. [16:25:03.0000] interesting that some internal slots exist for identification purposes 2021-04-06 [17:39:08.0000] re Issue 2373, something I don't understand: erights says that if `new Function(attackerProvidedString)` succeeds, then `attackerProvidedString` is a syntactically valid function body (agreed), and then says "that may then be safely concatenated in exactly this way without creating an injection attack". I don't understand how mere syntactic validity prevents an injection attack. Can't a valid function body nevertheless [17:42:10.0000] jmdyck you got cut off, I think? [17:42:35.0000] Can't a valid function body nevertheless be an attack? [17:44:48.0000] yes, but only once executed [17:45:50.0000] right [17:46:14.0000] ljharb, does `is-map` really need to know if `$Set.call(x)` throws? Would this still work as expected w/o determining if `x` were also a `Set` in this module? https://github.com/inspect-js/is-map/blob/main/index.js#L34 [17:50:41.0000] Bakkot: Is he saying this?: if `new Function(x)` doesn't raise a syntax error, then you can call the resulting function without fear of an injection attack. [17:50:52.0000] If so, that's what i don't understand. [17:59:24.0000] I believe he is saying that he has code which uses `Function` to check if something is a valid function body, and then discards the result and composes it with other code and `eval`s the result, in a way which is safe iff the code assumed to be a valid function body is in fact a valid function body [18:00:30.0000] this being the sort of thing he likes to do [18:00:33.0000] hm, ok. [18:00:44.0000] DerekNonGeneric: it's required because of a core-js bug, where some versions of it don't distinguish between Map and Set. [18:00:56.0000] DerekNonGeneric: iow, if not for core-js, that file wouldn't need any Set things at all [18:01:52.0000] wow, what a weird bug [18:04:53.0000] Bakkot: in that case, I'm surprised that he can guarantee safeness of eval'ing the composed thing merely by knowing that x is a valid function body. Unless the composed thing doesn't actually execute x, I guess. [18:05:03.0000] right, that's my assumption [18:05:37.0000] or at least does not immediately eval it, but perhaps instead stashes it somewhere and evals it in a very restrictive (`with (proxy)`) environment [18:06:09.0000] or not `with (proxy)` but defensive in some manner, at any rate [18:06:16.0000] that is his whole thing, with es-membrane and so on [18:06:56.0000] but not defensive enough to deal with x not being a valid function body. [18:07:44.0000] ok, i think i can kind of see how that makes sense, thanks. [18:11:50.0000] Bakkot: re 2374, we usually capitalize the first word of a NOTE (if it isn't an alias or some such) [18:12:00.0000] ah, nice catch [18:12:03.0000] one more for the linter [18:12:27.0000] there are a couple exceptions elsewhere [18:13:52.0000] jmdyck: node used to be vulnerable to `require` in that way, because the implementation used to just slap function text around the module contents and eval it [18:14:15.0000] jmdyck: so it's a legit attack surface. i just don't think it's that big a deal here since only one out of like a dozen implementations misinterpreted it [18:17:41.0000] ljharb markm's claim is that the new text, as of 2348, is easier to misinterpret [18:18:04.0000] jmdyck: I see we have two existing notes in violation of this new rule [18:18:06.0000] i mean, maybe, but xs's impl predates that for sure [18:18:39.0000] Bakkot: (that's what I meant by "there are a couple exceptions elsewhere") [18:18:51.0000] ah, totally missed that line [18:19:07.0000] xst parses the concatenation as an Expression, I guess? [18:21:39.0000] If anything, xst's bug is an indication that the *former* text is "easy to misinterpret" [18:23:35.0000] right [18:23:55.0000] altho, i'm also surprised we don't have a test262 case for this one [18:24:45.0000] we don't? ee [18:25:02.0000] issue comments imply we don't [18:25:13.0000] i haven't looked myself [18:25:52.0000] hm, lots of tests in built-ins/Function/ [18:27:50.0000] (a lot of which don't actually call Function!) [18:30:07.0000] I looked and couldn't find one [18:30:15.0000] and xs does run test262, so it probably would have caught it [18:31:00.0000] one could always modify https://github.com/engine262/engine262/blob/a1204a50231457ad6183573c6957267f66f094bb/src/runtime-semantics/CreateDynamicFunction.mjs#L29 to have the bug and run test262 with the modification and see if there are any test failures [18:31:07.0000] but I'm much too lazy for that at the moment [18:31:55.0000] Yeah, I couldn't find a test that tries to do something inject-y with Function() [18:34:26.0000] jmdyck https://github.com/tc39/ecmarkup/pull/315 will hopefully prevent my mistake in the future [18:34:52.0000] sidebar: I am looking forward to integrating 545 into the linter, to check AOs are called with the appropriate number of arguments [18:35:07.0000] can't yet check types, but even that step is going to help a fair bit [18:35:21.0000] this will also make the build a lot slower, probably, but what can you do [18:35:53.0000] I'm pretty sure my static analysis would have found wrong-number-of-args. [18:36:06.0000] probably! [18:36:16.0000] In fact, I'm sure it *did*, I'm not positive it found them all though. [18:36:26.0000] I am steadily reimplementing all of your static analysis, apparently [18:36:32.0000] heh [18:36:46.0000] except I get the advantage of being able to make the spec consistent first [18:36:55.0000] not fair. [18:42:11.0000] So editors are going to decide how to handle/format the weird cases, and we'll iterate on those, and 545 will be ready? [18:46:54.0000] or is there more to do? [18:53:07.0000] I will probably submit a PR making some stuff consistent first, namely the following: [18:53:15.0000] (maybe) drop Static Semantics prefix on AOs [18:53:15.0000] - move emu-notes which are between "It performs..." and emu-alg to just before "It performs..." [18:53:15.0000] - and emu-notes which are before the preamble to the same: GlobalDeclarationInstantiation, BlockDeclarationInstantiation, FunctionDeclarationInstantiation [18:53:15.0000] - split text in GetWaiterList into its own clause [18:53:15.0000] - "This operation" -> "It" for `sec-createsetiterator`, `sec-createmapiterator`, `sec-createarrayiterator` [18:53:16.0000] - the flatmap arguments thing [18:53:17.0000] - phrasing for LocalTZA [18:53:18.0000] - phrasing for HostEnqueueFinalizationRegistryCleanupJob [18:53:19.0000] - drop "Concrete Method" suffix [18:53:20.0000] - add

The abstract operation StringToBigInt takes argument argument.

[18:53:49.0000] and I suspect the thing we will decide for the weird cases is that they shouldn't be part of 545 [18:53:59.0000] but we'll discuss it [18:54:34.0000] and then I believe it will be ready to land, yes [18:55:00.0000] and I guess I'll also need to fix up ecmarkup a bit more [18:55:05.0000] oh! the other thing was SDOs [18:55:26.0000] did you want to land SDOs in a followup, or something else? [19:18:11.0000] ("flatmap" -> "FlattenIntoArray" ?) [19:18:18.0000] yeah that [19:20:28.0000] Well, in my master, I've disbanded the Annex-of-SDO-headers: each SDO header now appears in the first (and usually only) clause that defines the SDO. [19:20:51.0000] but I haven't pushed that to my 545 branch yet. [19:21:35.0000] right. so if you do push it to 545, there's potentially more to do there - ecmarkup doesn't support it yet, and I don't know what changes to the generated output will be implied [19:21:49.0000] if you do it in a followup then of course it doesn't matter for 545 [19:21:59.0000] Also, it'll raise the question of how to handle https://tc39.es/ecma262/#sec-static-semantics-tv-and-trv [19:26:13.0000] You could just split them into two separate clauses: there's only 4 simple cases in common. [19:35:32.0000] And I'm guessing that would allow uses of TV and TRV to autolink. [19:36:42.0000] I could do that right now, if you like. [19:42:28.0000] sure, that seems reasonable [19:42:46.0000] as subclauses of 12.8.6.1, perhaps, with the text currently at the start of 12.8.6.1 left where it is? [19:42:54.0000] so 12.8.6.1 would be [19:44:12.0000] I wasn't thinking they needed to be grouped. [19:44:19.0000]

Static Semantics: TV and TRV

\n

A template literal component [...] ... ... [19:44:40.0000] well, mostly I want to group them so that the text in 12.8.6.1 has an obvious place to go [19:45:01.0000] we could also rephrase it, but I don't see harm in grouping [19:45:19.0000] all but its last sentence is talking about TV [19:46:13.0000] it's talking about TV, but mostly applies to TRV as well [19:46:14.0000] and the last sentence is talking about TRV. so that seemed like a good split for that para. [19:46:38.0000] but TRV says it's similar to TV. [19:46:58.0000] /shrug [19:47:08.0000] I'm OK with splitting that text if you strongly prefer to do so, but still lean towards grouping them in one clause and leaving the text as-is [19:47:17.0000] I don't think there is harm in grouping such similar operations [19:50:37.0000] well, I'll pr what i've got, and editors can decide. [20:17:37.0000] Done. [20:18:40.0000] thanks! [20:19:29.0000] That doubling-up has been an occasional annoyance for ages, i'm surprised I didn't notice before how splittable it was. [20:21:22.0000] yay, autolinking works [20:34:47.0000] Bakkot: I think that `Function` example is still illegal under 2348, because you're missing a ')'. Instead, make the first arg ') /*' or the second arg '*/ ) {' [20:37:27.0000] ah, yeah, thanks [20:38:18.0000] I'm sorry that problem with 2348 didn't occur to me. [20:41:15.0000] it happens, no one else caught it either [20:43:42.0000] I am annoyed at myself for not catching it; I work in security, and this is an instance of a very common class of parsing-related security bug, where the parse of the composition of two things has different properties than the composition of their individual parses. 2021-04-07 [10:20:35.0000] Bakkot, ljharb, it seems like checking for internal slots using the `prototype.has()` is only possible for keyed collections (`Map`, `Set`, `WeakMap`, `WeakSet`) since the other builtins are missing `prototype.has()`... [10:31:32.0000] using `Object.prototype.toString()` has become a lot more appealing due to its simplicity despite its unreliability [10:32:42.0000] DerekNonGeneric: sure, the mechanism is unique for every builtin [10:32:54.0000] DerekNonGeneric: which is why i made the packages, so you don't have to know all those details [10:33:14.0000] DerekNonGeneric: it also depends on the use case. if it's for debug info, https://npmjs.com/object-inspect has you covered [10:38:55.0000] I find it quite troubling that this isn't easier to do... [10:39:43.0000] DerekNonGeneric: dan and i are planning to reintroduce a proposal sometime this year to make it easier [10:40:01.0000] DerekNonGeneric: i'll ping you when i make the repo; knowing your exact use cases would help [10:42:37.0000] ljharb, yes please do let me know once that is underway; the use-case is evident this tweet (runtime typechecking for strict function inputs) https://twitter.com/buildsghost/status/1378091631379767296 [10:45:23.0000] DerekNonGeneric: i don't believe typescript's types are anywhere near as robust as "has internal slots" tho [10:45:41.0000] DerekNonGeneric: ie if your goal is to match typescript, `instanceof` is probably about the same semantics for most things [10:50:25.0000] `instanceof` doesn't work cross-realm (iframes), but there must be a way to replicate the logic of `instanceof` in userland (something like comparing whether it has the correct prototype) [10:51:57.0000] DerekNonGeneric: typescript doesn't understand realms so that shouldn't matter [10:52:17.0000] there is. instanceof is basically calling the Symbol.hasInstance method when present, and checking the .constructor and/or [[Prototype]] (i forget which) when not [10:55:53.0000] DerekNonGeneric that tweet does not make the use case clear to me, fwiw [10:56:13.0000] checking _primitives_ is an obvious thing to want, but `typeof` accomplishes that [10:57:29.0000] for objects, my position is that your code should not care whether it's given an actual Map or a thing which conforms to the interface of Map [10:58:04.0000] making it easy to distinguish the two encourages distinguishing between those two cases, and most code should not distinguish [11:03:48.0000] Bakkot, yeah, that pretty much sums up how I feel about objects too (conforms to the interface), but making such a check sounds expensive (need to determine if the object in question has all the same properties as an instantiated builtin) [12:18:29.0000] i'm just reading https://tc39.es/ecma262/#sec-returnifabrupt -- shouldn't "algorgithms steps" be "algorithm steps"? [12:19:51.0000] I don't see "algorg" anywhere in https://tc39.es/ecma262 [12:19:57.0000] me neither [12:20:02.0000] sorry [12:20:06.0000] "algorithms steps" [12:20:17.0000] ah, yes. [12:20:18.0000] not helpful when i typo the thing i'm trying to point to :P [12:20:59.0000] yup, that looks wrong to me. [12:21:02.0000] seems like it'd be clearer without the plural in the few places it's in, yeah [12:21:26.0000] i mean maybe technically could be "algorithms' steps" [12:21:31.0000] but that is kind of weird also [12:21:35.0000] agreed [12:23:08.0000] Goes back to ES6: https://262.ecma-international.org/6.0/#sec-throw-an-exception [12:23:54.0000] how did you find that out so quickly? [12:24:04.0000] just ctrl+f? [12:25:19.0000] `git log -S 'Algorithms steps'` and then looked at the oldest commit. Could also have used `git blame`. [12:25:52.0000] That showed it goes back at least to ES6, because that's the oldest version in git. [12:26:05.0000] so then i did a ctrl-f in 5.1 and got no hits. [12:27:02.0000] git log -S. thanks. didn't know that one [12:27:14.0000] It's ridiculously useful. [12:27:28.0000] Also git log -G [12:36:57.0000] i just āŒ˜-F'd in the page 2021-04-08 [08:43:46.0000] what if instead of making Math methods work on bigints, we expanded the methods on the prototypes of numerics [09:54:10.0000] Anyone known why Atomics.store uses ToIntegerOrInfinity but Atomics.wait uses ToInt32? 2021-04-09 [18:26:05.0000] well, Atomics.store has its value get rounded later when writing into the TypedArray, whereas this doesn't occur for Atomics.wait--the rounding needs to be explicit there [18:56:23.0000] littledan: okay, but shouldn [19:03:27.0000] say Atomics.wait has a Float64 array. So _w_ is going to be an arbitrary float, right? So why would you compare it to _v_, which is an Int32? [19:05:25.0000] ah, it can't be Float64. [19:07:19.0000] the call to ValidateIntegerTypedArray forces Int32Array or BigInt64Array [08:26:26.0000] pd4d10 [08:26:39.0000] sorry i am getting irc wrong... [09:44:16.0000] no worries, ****** is all i see [10:30:36.0000] Play with Hack-style pipelines (with #-placeholders). (Ignore the errors): https://www.staging-typescript.org/play?ts=4.3.0-pr-43617-2#code/PTAEAUBsEME8HMBOB7ArgOwCagGbMaABLQDGA1gLQDOALrJAKagAOAlsw5K+g1aABY0azKgC4Q8VjX6oARgDoSyALbAAVlQol+yVsGYpmyKtEgV+pSmw5VgAKBCgAKrA4BlEonY0IAJVECQiLiwJLScooqwACyrJ7GyDg0wC7unt76qJCQwAAsAMwAbACMAOwOYADq+GR8-AyITJi8 [10:30:37.0000] bDRM0kwARABq0F7QsoygAOQAFLFUVNzwAJTDoKx8qFQM2LIMeI2g69Og0JOs8DyY8p2gDSiIVHZ2w+DsnNy8AITDdqAfoAA+AHygAMTyRjoeDSd6fX6gaLQaTyIwAd1G-wANKAAEwzcEfSFKdBUZCMIHIeBImYAblAjmKAAZqXYgA [12:26:03.0000] Pokute: Thatā€™s really cool. Looks like you made a pull request at https://github.com/microsoft/TypeScript/pull/43617, too. Do you anticipate being able to add support for choosing different topic tokens? [12:28:12.0000] Pokute: I happen to have been working on Babel support for Hack pipes, too. You can track that issue at https://github.com/babel/babel/pull/11600. One thing that I plan to do is to force the user to specify which topic token they want: `@`, `%`, `#`, or `?`. You might want to look into doing the same with your TypeScript patches. [12:42:46.0000] Bakkot: In https://github.com/tc39/ecma262/pull/2378#discussion_r610843513, when you say "mean", do you mean "mention"? [12:43:39.0000] I do mean that yes [12:44:15.0000] thx [13:07:14.0000] jschoi: It might be difficult to support different topic tokens for hack-style pipelines in TS. [13:35:47.0000] Pokute: I had figured as much. It would be a while anyway until TC39 decides whether to advance it and the topic token becomes worth bikeshedding. Either way, this looks really cool. šŸ‘ [13:54:58.0000] jschoi: My intention is just raising awareness, interest and to get more discussion ongoing. While hack-style might not be my favourite one, I will still advocate for it if it's the closest one to succeeding. [13:56:41.0000] I believe that after passing the first version, whichever it might be - F# or hack, it would be really fast and simple to add another one with a different syntax that does the other usecase (placeholder token / unary function calling) [13:58:12.0000] Pokute: Yeah, that definitely makes sense. [13:58:59.0000] Thus it ends up that peoples' preferences delay the pipelines for everyone since they think that the initial single way the pipeline operator ends up as is the final way with no extensions. [14:01:17.0000] Especially if hack-style is implemented first, there's no real need for partial application (I made a typescript PR for that one too). [14:24:41.0000] thought of something funny. if you had a function f which when given empty template `` returned a new function f2, you could pretend it was f-double prime :D f``. [14:25:01.0000] could do any even number.. :p 2021-04-10 [20:40:14.0000] The more I look at the discussion around pipeline operator, the more it hurts. Now I feel like the bruteforcing / stealthing it through might be the only feasible way. [20:44:50.0000] Not really through the TC39, but it fels like all new participants in the discussion are way too attached to one method. [20:46:50.0000] It's like a war between two kinds of people, half of which want their peanut butter & jam sandwitchies to be PB on top, jam on bottom and other half jelly on top, PB on bottom. No-one really appreciates that turning the sandwitch over is so much easier than the status quo of having bread, PB and jam served in separate locations. [20:51:41.0000] šŸ‘€ [02:11:36.0000] should things like: new.target be treated as three tokens where we can put whitespace between? like new . target? https://tc39.es/ecma262/#prod-NewTarget to me it's not clear from the production if that is the case, or if it's just the sequence of code points: "new.target" [02:16:39.0000] i suppose the lexical rules would already have identified it as like identifier, punctuator and identifier though so... i guess when you're applying the grammar, they'd already be three tokens [03:11:03.0000] i guess i should be using the lexical parser to pass tokens to the grammar productions.. or getting my grammar productions to consume tokens via the lexical goals before checking the grammar [05:34:15.0000] aradesh: in the NewTarget production, the single colon tells you that it's in the syntactic grammar, so yes it's 3 tokens with optional whitespace in-between. The lexical grammar cannot generate/recognize `new.target` as a single token. [05:38:46.0000] See https://github.com/tc39/test262/blob/main/test/language/expressions/new.target/asi.js which tests various kinds of separation between the 3 tokens. 2021-04-13 [21:45:12.0000] > Error constructor for test and validation frameworks that implements standardized AssertionError specification. [21:45:43.0000] what is this readme talking about? https://github.com/chaijs/assertion-error [21:46:13.0000] do we have a standardized `AssertionError` specification somewhere? [21:47:12.0000] maybe "what node does"? not aware of anything [21:47:46.0000] nope, i compared the two and they are way different [21:48:11.0000] DerekNonGeneric: https://github.com/chaijs/assertion-error/issues/1 implies it's just a thing they were hoping to standardize, that never was [21:56:27.0000] ljharb, a standardized specification for this sounds useful, actually [21:58:26.0000] ljharb, the one node uses is quite complex compared to this one [22:42:14.0000] deno just copied node and wrote it in typescript [22:49:47.0000] amp puts a `.expected` property on `Error` classes, which might mean that they should actually be using an `AssertionError` instead https://github.com/ampproject/amphtml/blob/main/spec/amp-errors.md [22:50:26.0000] right but AssertionError isn't a thing [22:50:39.0000] a standardization attempt from 8 years ago isn't "a standard" [22:53:14.0000] seems like a fairly common pattern, but there is no ECMAScript standard for it, which could be useful (even for browsers) [22:58:03.0000] common in which libraries? [22:58:30.0000] not "throwing an error when an assertion is failed", ofc, but "throwing something that is named and has an interface of some kind of common `AssertionError`"? [23:00:05.0000] node & deno are using this and chai & jest too, which even went as far as formatting node assertions errors quite nicely https://github.com/facebook/jest/blob/034cd343189db57d3b957170aa2d7f869ca4c9ee/packages/jest-circus/src/formatNodeAssertErrors.ts [23:02:03.0000] you just said you compared them and they are way different [23:02:51.0000] the chai one is different than node & deno. the chai one is much more simplified [23:03:19.0000] ok, but deno aside, chai has one standard, node has another, presumably other assertion libraries have their own [23:03:24.0000] so where's the common thread [23:05:25.0000] ljharb, i think this interface `AssertionErrorDetailsDescriptor` could be the common thread https://deno.land/stdāŠ™0/node/assertion_error.ts#L351-L357 [23:07:15.0000] DerekNonGeneric: if so, you could make a proposal for it documenting all the existing uses that would be a subset of [23:14:01.0000] sgtm [13:57:15.0000] ljharb, got a rough draft so far, but still working on it (turned out to be more work than expected) https://github.com/DerekNonGeneric/proposal-assertion-error [14:13:29.0000] DerekNonGeneric: is there a reason it couldn [14:13:40.0000] DerekNonGeneric: couldn't be a normal error with a `cause` object, with those properties? [14:13:55.0000] like in userland i mean [14:37:48.0000] perhaps for a polyfill? would need to read up on that proposal a bit more, but that would defeat the point of standardizing `AssertionError` in the first place since you can't say that you're providing a consistent (assertion library-agnostic) API for error reporters to consume [14:43:00.0000] gotcha 2021-04-14 [07:42:38.0000] Bakkot: re https://es.discourse.group/t/is-the-api-surface-of-the-spec-machine-readable/699/8: Ah, you're thinking that post-545, ecmarkup will generate the aoid, so it doesn't need to appear in the source. I didn't notice that in https://github.com/tc39/ecmarkup/tree/structured-header 's example (and you didn't call it out), so that's another thing I'll need to tweak in 545. [07:47:06.0000] jmdyck yeah. it's a small thing, though 2021-04-16 [16:44:37.0000] should `"\199"` be valid json 2021-04-17 [17:01:34.0000] no [17:01:55.0000] I'm also pretty sure it isn't [17:01:59.0000] but it shouldn't be, also [17:28:55.0000] Curious. The resolve function in a promise has a reference to the promise more or less right? So code like: new Promise(resolve => window.resolve = resolve) That's what causes the promise to not get GC'ed even if a direct reference to the promise doesn't exist? [17:29:49.0000] I presume, yeah. The resolve fn has to hold a strong ref to its associated Promise. [17:30:17.0000] I guess theoretically it could hold a weak ref it was written defensively; you can't get at the promise *using* the resolve function. [17:50:38.0000] Resolver maybe not blocking it to be GCed as TabAtkins said, but reject will. Cause when the promise rejects, a host hook will be called to notify that unhandled rejection [18:15:55.0000] akirose only if the host actually does anything with that host hook; if it doesn't it can GC the promise without that being observable [18:16:01.0000] *jackwors, sorry aki [18:16:04.0000] *jackworks [18:16:05.0000] ugh [18:16:07.0000] typing [18:16:34.0000] lol [04:33:04.0000] Almost ready to have another playground for Pipelines: https://media.discordapp.net/attachments/640177429775777792/832755342109573170/unknown.png [08:59:11.0000] Very cool! (Tho I am *highly* doubtful that the gain of avoiding putting a `(#)` at the end of `Math.round` there is worth the complexity of a second pipeline operator and accordingly separate syntax model for the RHS.) [12:36:13.0000] TabAtkins: The *additional* complexity of second pipeline operator is elemental compared to introducing the first one, especially if topic-styles are implemented first. [12:39:05.0000] Then we have to weigh in the people who strongly prefer one style over another, whichever way they prefer. This might be the compromise with least opposition. [12:44:25.0000] Obviosly with so many years behind us, the issue doesn't seem to be not whether one style works better than the other, but whether someone prefers on over another. This is one way where complaints like: "We don't need this style because I don't use it and it introduces compexity" or "It's ugly" or "The character cost is way too high!" are seen as [12:44:26.0000] ridicilous and ineffective. [12:52:37.0000] Also, adding full support of these features to TypeScript, which might be one of the most complex JS-style parsers is kind of disproving that the implementation is too difficult / complex. I've done protos of partial function application, Hack pipelins and F# pipelines (without await) with no prior knowledge of TypeScript codebase or even compilers [12:52:38.0000] really in a reasonable amount of time. [13:17:11.0000] Pokute: remember tho, the future is longer than the past. it'd be better to wait 10 more years to get any form of pipeline than to be stuck with the wrong one for the next 1000 [13:29:24.0000] god I hope we are not writing new javascript 1000 years hence [13:29:56.0000] fully expect some to be running somewhere, at least if there is anything left on the planet [13:30:49.0000] our mistakes will live *forever* [13:31:07.0000] https://twitter.com/ktemkin/status/1346734616749563905 [13:31:30.0000] lol [13:31:36.0000] https://twitter.com/evntdrvn/status/1346816967001444352 [13:54:47.0000] Not doing anything can be a mistake too. [14:00:21.0000] Pokute: sure. but often much less of one than doing the wrong thing. [14:00:41.0000] And by someone's standards, there have already been mistakes in JavaScript, and the mistakes will be made in the future too. Thus mistakes by some standard are always made. What I'm aiming here is a reaching compromise where most can agree that no more universally agreaable solution is seen. [14:01:11.0000] that we're stuck with some mistakes should encourage fewer, not excuse more [14:01:22.0000] (ftr i like pipeline and want it to advance) [14:01:31.0000] but i don't think "it's been so long" is a compelling argument [14:04:01.0000] I think that "it's been so long" is a valid argument for overcoming dislikes/distastes/preferences. More technical arguments are a different matter of course. [14:05:42.0000] It's not always clear of course which arguments are less of personal likes and which genuinely affect most people. :-) [14:13:57.0000] This is why I don't really mind which pipeline proposal variant ends up at the top. Both hack- and F# variant proponents favor their own, but disregarding other side's wants feel to me only slightly more justified than "foo.#bar for private members is ugly" -argument. A tactful person would offer to take the one character of extra syntax tax (|>>) [14:13:58.0000] for his own variant. [14:52:23.0000] just been reading the specification. we have these four lexical goals defined: InputElementDiv, InputElementRegExp, InputElementTemplateTail and InputElementRegExpOrTemplateTail... but they're not really used any where other than defining them... it implies the idea is that according to the grammar, a lexical tokenizer ought to use one of those four as its goal, but it never really tells you when those cases [14:52:24.0000] are [14:58:28.0000] i guess the idea maybe is to just consult the production you're parsing, and determine if eg a regexp is allowed at that point, and set the goal accordingly? [14:59:24.0000] and i suppose, if regexp is allowed, /hi/ is parsed as the regexp rather than the punctuator / because it's longer? 2021-04-18 [18:03:02.0000] aradesh: https://tc39.es/ecma262/#sec-ecmascript-language-lexical-grammar paragraph 2 tells you when to use the different InputElementFoo lexical goals [18:06:03.0000] Your phrase "consult the production you're parsing" suggests you're thinking of a top-down parser, which may not help. [18:07:47.0000] Instead, think of a bottom-up parser: at any state, you know all the 'in-progress' productions, and so know all the tokens that would be valid at this point. You can then use that to pick the lexical goal. [18:11:03.0000] re "if regexp is allowed, /hi/ is parsed as the regexp rather than the punctuator / because it's longer?": No, if a RegExpLiteral is permitted, then you're obliged to use InputElementRegExp[OrTemplateTail], which does not derive (cannot recognize) the DivPunctuator / [03:38:34.0000] https://www.staging-typescript.org/play?target=99&ts=4.3.0-pr-43617-7#code/PTAEAUBsEME8HMBOB7ArgOwCagGbMaABLQDGA1gLQDOALrJAKagAOAlsw5K+g1aABY0azKgC4Q8VjX6oARgDoSyALbAAVlQol+yVsGYpmyKtEgV+pSmw5VgAKBBFofACqkpoAKrpoiWKAAxDBIaVmR0UABBZmYuEmhQ8NAqVBj8GlBpFFR4fkz+JgAfAD5i0ApkDkQE-HkHMBdYDgBlEkR2DPAAJVEBIRFxYElpOUUVYABZVjbjZBwaYEaWto79VEhIYAAWAGYANgBGAHY7 [03:38:35.0000] OyV0WkyAeVAAXlAeAHcIFGVWKgYAHlp29HhigAUAMQvGQkAAbgwAJR3MoAbzsoGSDBoLlYygYaBoQJht2KiNACKRSIA5NBHtApAxMCTQCUyiCqGDIQBuAkAXwANKAAKwABj5ULZ7Khp3OlwY2mQDAI92csHQJFAAOYvXAr3eXzhmWQzRov3gvWg6H87LKhUJOr1BqNJtAIthhIJSOYzuJSJKoHJlIyAGI3e7Pb7QABqUC02lh-3uwOlUDisEMeSQZDwYWnSU6GUAmhXIVi8KXapYFQASXQGXuAOU0AAHr10KhlLIZbj8e6Jgl+PJi5gVADRTHiUHQAAqUA12sB4dxzvSeT64Js [03:38:35.0000] uy9ssVgEAJkFdLjCcYydTbMz0sQAJ2Avzq+U5exW5h9NAx5lbKAA [03:38:52.0000] That's pipeline operator with |>> [03:40:08.0000] So hack pipeline operator with # token and |>> for F#-like pipelines. [06:45:11.0000] aradesh: I replied to your parsing question [07:07:54.0000] jmdyck: could you post it again? [07:07:58.0000] as i had gone to bed [07:08:06.0000] https://freenode.logbot.info/tc39/20210418 [07:08:21.0000] thank you [07:10:15.0000] jmdyck: yeah in my typing i forgot DivPunctuator wasn't Punctuator. [07:11:27.0000] ah 2021-04-19 [21:37:42.0000] exit [21:37:45.0000] exit [21:38:00.0000] part [21:42:21.0000] ^C šŸ¤”? [07:41:34.0000] I fully support Dan. [11:54:51.0000] here's the prior discussion on GetOptionsObject in case anyone is curious https://github.com/tc39/notes/blob/master/meetings/2020-09/sept-22.md#getoption-in-ecma-262 [15:14:05.0000] the spec for the import assertions doesn't seem to state what happens when an assertion fails https://tc39.es/proposal-import-assertions/ [15:18:58.0000] DerekNonGeneric: the IfAbruptRejectPromise calls should? [15:22:49.0000] ljharb, that part is outside of this spec, which doesn't seem to specify what happens if the host doesn't have a key for the type specified [15:25:12.0000] :s [15:25:53.0000] > If the type is invalid, then an exception is thrown and module loading fails. [15:26:19.0000] that was stated in example host integration tho https://tc39.es/proposal-import-assertions/#sec-host-integration [15:27:57.0000] guess that part is supposed to be determined by the host [15:30:21.0000] the algorithm for this specification seems a bit confusing to me... almost as if it has circular logic [15:33:02.0000] file an issue asking for clarification :-) [15:54:24.0000] Is there a good way to get contact info / their preferred method of communication of TC39 delegates? [15:59:40.0000] Opening new issues / randomly placed github mentions might work, but seem a bit wrong if I'm asking about the current progress. [16:00:13.0000] if you are asking about an active proposal, an issue on the proposal's repo is the appropriate place [16:03:26.0000] So you would encourage posting a "Are you going to present this proposal at next TC39 meeting" -issue? [16:05:25.0000] *planning [16:06:01.0000] I wouldn't say I'd _encourage_ it, and you should probably be more general about it - instead ask "what's the status", e.g. - but I personally would consider that a reasonable thing to do, yes. assuming you've done due diligence about checking upcoming agendas, recent activity on the proposal repo, etc [16:06:26.0000] if you want a less formal place, the discourse is good for that sort of thing: https://es.discourse.group/ [16:06:40.0000] but less likely to reach the relevant delegates; otoh someone else who knows might chime in [16:13:41.0000] Ok! Thanks for the help! 2021-04-23 [07:50:26.0000] I'm getting crazy with JS a bit now :/ [07:51:06.0000] I want to do the following: [07:52:04.0000] - put URL query parameters as a string such that the value of one parameter is escaped with "encodeURIComponent()" [07:52:49.0000] const params = new URLSearchParams(); [07:52:54.0000] if (languageData?.subject) {params.append('subject', languageData.subject);} [07:52:59.0000] if (languageData?.content) {params.append('body', encodeURIComponent(languageData.content));} [07:53:55.0000] I tried without encodeURIComponent also. And later using params.toString() gives the result which modifies the value of the "body" parameter. [07:54:27.0000] Why does it do that? [11:51:51.0000] croraf: fwiw, that's a web API, not JS, so asking in #whatwg might be more helpful [11:56:36.0000] croraf: ask in ##javascript and i'll be happy to tell you about why USP isn't sufficiently useful, and point you at some alternatives [12:54:29.0000] ^ he means #javascript [12:57:16.0000] jridgewell: #javascript exists? [12:57:51.0000] it's one of those invite-only or like... reserved channels it seems [12:58:03.0000] no, i mean ##javascript [12:58:15.0000] yeah like the community channel right? [12:58:31.0000] #s are usually the more official ones IIUC [12:58:35.0000] on freenode, a single # is for "official" channels, "##" is for unofficial ones, and neither ecma nor oracle has claimed or appointed anyone for the official onel. [12:58:46.0000] right [12:59:04.0000] now that we have Oracle in TC39 :smirk: [13:24:41.0000] Whoops, sorry 2021-04-26 [11:25:25.0000] https://arxiv.org/pdf/2104.07460.pdf [11:35:11.0000] interesting [11:57:09.0000] I am glad they published their code, but the docs on this repo leave something to be desired https://github.com/NWU-NISL-Fuzzing/COMFORT [11:58:55.0000] whoops [11:59:08.0000] actually I think webkit's gotten bugs from them before [11:59:27.0000] didn't click until I saw those acronyms [12:00:19.0000] "We use GPT-2 to generate test JS programs." is pretty neat [12:04:28.0000] bah: listing 13 says "This is an undefined behavior in ECMA-262", but it isn't [12:04:46.0000] don't know where they got that idea [13:25:04.0000] majority voting thing is probably the wrong heuristic [13:25:29.0000] i do like that they at least _asked_ the question "how useful are our bugs" [13:25:37.0000] i dislike their answer, but at least they're self aware enough to ask [13:28:12.0000] https://tc39.es/ecma262/#sec-numericvalue in this section, why is the option given in how to convert a numeric literal MV to the number value? why not just make it the number value of the MV? i mean it's only going to be edge cases which are effected, but you could still in theory get ES implementations which read decimal numbers differently [13:29:56.0000] at the very least, not all real numbers are representable in ieee754 floating point, not sure what "make it the number value of the MV" means [13:30:34.0000] it's defined in this section: https://tc39.es/ecma262/#sec-numericvalue [13:30:55.0000] basically, the closest floating point number to the MV, and if there is a tie, take the even significand [13:31:46.0000] yes, that section is defining how to get a Number value from an MV [13:32:04.0000] i don't understand what you mean by "why not just make it the number value of the MV" [13:32:37.0000] because it does this: takes an MV, gives you the option of rounding it in two different ways, and says take the NV of the result [13:32:43.0000] and it doesn't care which you pick [13:33:00.0000] for it to be a conforming ES imp [13:33:24.0000] just wonder why they do that, rather than just say take the NV of the MV [13:34:32.0000] you seem to be asking why is there choice in the "NV of MV" definition, which the editors spent some time discussing but didn't have the time to fuzz implementations to determine what the reality is [13:37:36.0000] i guess most implementations probably do just compute the number value of the MV, as it'll still satisfy the condition. i'll have to experiment [13:37:56.0000] i very much doubt most implementations compute the number value of the MV [13:38:20.0000] parsers don't parse into an arbitrary precision decimal format and do rounding [13:38:39.0000] oh. well it's just not a huge amount of extra overhead is all. [13:38:44.0000] to do it exactly [13:39:02.0000] fairly simple problem to solve [13:39:33.0000] really? [13:40:19.0000] yeah, if you can compute decimal expansions of rational numbers with power of two in the denominator, you can work out which float it'll be closest to [13:41:19.0000] clinger's paper led me to believe otherwise [13:42:04.0000] can result in quite a long decimal expansion for some of the extreme cases though, like the smallest possible float [13:43:22.0000] what's a library that implements this algorithm? and what is a "not a huge amount of extra overhead"? [13:43:41.0000] dunno. but i tested it in python and it does it exactly [13:43:53.0000] i'lll see what some of the browser versions of ES do [14:14:17.0000] firefox seems to do it exactly [14:14:50.0000] 100000000000000033306690738754696212708950042724609375e-53 is the exact midpoint between the floating point with exponent 1023 with significand 1 and 2 [14:14:59.0000] if you change the last digit down to 4, it effecets the result [14:15:59.0000] or at least, it does it to that many dp [14:16:36.0000] changed the end to 4.99999 (lots of 9's) and it still does it [14:16:57.0000] so seems it checks the whole value in this case [14:18:27.0000] ah maybe i need one where it rounds down to test better [14:20:18.0000] 100000000000000055511151231257827021181583404541015625.0e-53 is between the significands 2 and 3, and if you add 0000001 after it, it affects the result, even with many hundreds of 0's [14:20:39.0000] so seems firefox has the hang of it 2021-04-27 [12:18:26.0000] shu: i tested pretty much the most extreme value possible - the midpoint between the smallest non-zero float and zero, in firefox. and it can detect the last significant figure changing (752nd place) [12:34:57.0000] aradesh: thanks for the info 2021-04-29 [15:26:17.0000] Decorators being at stage 2, Iā€™m wondering whether its `@(expression)` syntax is set in stone: would using `@{expression}` instead be a possibility? The reason why I ask is because Hack-style pipes could use `@` as their placeholder tokenā€¦if it werenā€™t for decoratorsā€™ `@(expression)` syntax conflicting with function calls. [15:28:31.0000] ā€¦I also just realized that its syntax restriction to identifiers and property chains of identifiers is pretty similar to the original smart-mix pipe proposalā€™s syntax restriction. I am amused, heh. [15:29:31.0000] jschoi: imo the conflict would be conceptual, whether or not there's a grammar conflict [15:35:42.0000] ljharb: Thatā€™s certainly possible. I wonder if that might be a strong-enough reason not to bother adding support for trying `@` as a placeholder in the Hack-pipes Babel plugin, in addition to `#` and maybe `%` and maybe `?`. Hm.