2020-01-02 [20:41:09.0000] rkirsling: searching is easier without having to set up a project search kind of thing [20:44:04.0000] hmm, is it though? find in directory shouldn't be harder than find in file, plus the search is *completely* disabled right now via the GH UI since the file is too big [22:03:13.0000] rkirsling: locally [22:03:31.0000] right I addressed that first [22:04:32.0000] "find in directory" isn't easy to do on a stock vim setup, for example. not every editor has an easy find-in-project mechanism. [22:05:20.0000] but if vim is your go-to then surely grep is part and parcel...? [22:06:34.0000] my level of vim expertise means i'd exit vim, grep for the file, and open the two files manually [22:10:18.0000] could use multiple terminal sessions [11:42:23.0000] rkirsling: yeah i like interactively going through search results in my editor [11:42:45.0000] rkirsling: i can grep, but it's a more sophisticated to set up a thing where you can cycle through via editor buffers across multiple files [11:43:36.0000] rkirsling: it's a good point that GH disables the search though [11:45:02.0000] your editor can't just automatically search down whatever your cwd is? [11:45:48.0000] well actually i guess gui editors don't have a cwd [11:50:48.0000] that does not sound like behavior i want normally [11:51:04.0000] certainly not automatically [11:55:03.0000] works pretty well for me [11:55:21.0000] obviously you have to blacklist node_modules and .git and whatnot but other than that 2020-01-03 [16:20:46.0000] regardless of the multifile discussion though, does anybody have thoughts about the styling of notes that I had mentioned? [16:21:03.0000] I can open up an issue to discuss, just not sure whether 262 is the right repo or not [16:25:13.0000] rkirsling: which styling, the color contrast? [16:25:38.0000] rkirsling: it's just css; probably easiest to open a PR and the render preview can illustrate the difference [16:26:07.0000] like having a light orange background instead of a grey bar on the left, say, in a similar fashion to HTML / WASM specs [16:26:23.0000] yeah that's what I was thinking [16:26:26.0000] cool. [16:27:02.0000] be sure to check the print stylesheet manually too, just to make sure it's sensible [16:27:48.0000] oh good call, I wouldn't've thought of it [16:33:36.0000] ljharb: should FunctionDeclarationInstantiation 28.f.i.5 be Perform instead of Call? [16:36:18.0000] devsnek: typically Perform is when the return value doesn't matter, yes (https://tc39.es/ecma262/#sec-declarative-environment-records-initializebinding-n-v has one but it's not used in https://tc39.es/ecma262/#sec-functiondeclarationinstantiation). i also see 22.e, and 27.c.i.3, and probably others [16:36:27.0000] devsnek: want to make a PR that cleans up the side-effecty uses of Call? [16:36:36.0000] (on abstract ops only ofc) [16:36:42.0000] maybe [16:36:49.0000] i've only ever seen it this once [16:36:57.0000] lol this comment is a riot https://github.com/tc39/ecma262/issues/875#issuecomment-292671155 [16:38:16.0000] now i'm excited for this novel [16:38:39.0000] The Pragma Diaries [16:53:10.0000] i'm seeing assertion failures with that eval change [16:53:16.0000] still trying to debug it [17:05:34.0000] ljharb: you gave thumbs-up to https://github.com/tc39/ecma262/pull/1791#discussion_r362648352, but it doesn't appear to have affected the merge [17:10:46.0000] whoops, i may have missed it, I’ll add the fix in shortly [17:11:29.0000] i should make a shortcut for this `git -c color.ui=always diff | awk '!/\/\//{print}'` [17:11:58.0000] or find a way to enable syntax highlighting in diffs [17:18:29.0000] git diff seems to default to --color=always on my mac [17:18:49.0000] what's the awk command for? seems to just print it all out instead of entering a scrolly view [17:22:01.0000] rkirsling: it ignores comments [17:22:19.0000] ohh [17:22:25.0000] difficult to find problematic line when it looks like this https://gc.gy/45719539.png [17:23:08.0000] hah [17:24:15.0000] but then i realized [17:24:18.0000] instead of hiding lines [17:24:25.0000] why not just syntax highlight the diff [17:24:31.0000] so now i'm going down an entirely separate rabbit hole [17:25:52.0000] lol [18:10:25.0000] man this eval change is really giving me trouble [18:10:54.0000] https://gc.gy/45722454.png [18:17:40.0000] i think i need to rewrite all the iterator binding initialization stuff 😢 [19:41:44.0000] jmdyck: fixed, thanks for the catch https://github.com/tc39/ecma262/commit/cb73c69d861db21506c0246197fd87b723d6cdb4 [20:12:18.0000] ljharb: no problem [20:21:20.0000] uhhhh speaking of notes [20:21:26.0000] what happened here? https://tc39.es/ecma262/#table-42 [20:21:40.0000] it not only spills but isn't horizontally scrollable [20:21:54.0000] hm [20:23:29.0000] in spec.html, "gives examples of the ExportEntry record fields" is referencing table 42 [20:23:43.0000] but somehow table 48 shows up [20:24:02.0000] let me do a bisect [20:25:17.0000] no, it's referencing the thing whose id is "table-42", which happens to currently be Table 48 [20:25:25.0000] ah [20:26:00.0000] then in that case, it seems like all those note-d tables should be hoisted outside of the emu-note [20:26:57.0000] or hmm [20:27:16.0000] i'm not really sure. it looks *weird* to have the tables inside a note, but that one table's the only one that's "too wide" such that it's a problem [20:32:33.0000] yeah hm [20:34:33.0000] wow, that table barely can be said to fit even if it is hoisted [20:35:14.0000] the first column is
 so white-space: pre, and the other columns can't be any smaller because of the header text

[20:35:32.0000] 
right

[20:35:49.0000] 
I'm struggling to come up with a suggestion

[20:36:20.0000] 
make your browser window really wide :)

[20:36:36.0000] 
lol

[20:36:52.0000] 
and print sideways?

[20:36:54.0000] 
:p

[20:37:41.0000] 
hm, yeah, what does it look like in the pdf

[20:38:55.0000] 
lol even if i make the `` font-size 50% the table stlll doesn't fit

[20:43:13.0000] 
In the ES2019 PDF, it *almost* fits: in the rightmost column, the rightmost character gets trimmed

[21:21:17.0000] 
ok sanity check

[21:21:57.0000] 
by step 25 of FunctionDeclarationInstantiation

[21:22:26.0000] 
is `env` registered to the surrounding context in any way

[21:22:30.0000] 
i don't think it is

[21:23:17.0000] 
"registered"?

[21:23:37.0000] 
like attached to the callee context

[21:24:08.0000] 
i think argument initializers are broken rn

[21:24:32.0000] 
`env` is set in 19.b or 20.c; that doesn't do what you're asking?

[21:24:52.0000] 
but it isn't registered to calleeContext right

[21:25:01.0000] 
imagine `(function(a, b = a) {})`

[21:25:09.0000] 
IteratorBindingInitialization would create `a`

[21:25:14.0000] 
because it gets passed `env` explicitly

[21:25:24.0000] 
but then in `b = a`

[21:25:35.0000] 
`env` is not attached to the context on the stack

[21:25:37.0000] 
so you get a reference error

[21:26:21.0000] 
shu: ^

[23:07:12.0000] 
ljharb: this is some impressive house-cleaning you're doing today

[23:07:12.0000] 
lol

[23:07:30.0000] 
:-p

[13:20:44.0000] 
ljharb: was there recently an issue or plenary topic about built-in functions appearing to be a weird mix of strict and not strict

[13:20:54.0000] 
i feel like there was but i can't find anything on it

[13:21:34.0000] 
Question re:

[13:21:44.0000] 
> If the phrase “[lookahead ∉ set]” appears in the right-hand side of a production, it indicates that the production may not be used if the immediately following input token sequence is a member of the given set. The set can be written as a comma separated list of one or two element terminal sequences enclosed in curly brackets.

[13:21:46.0000] 
> For convenience, the set can also be written as a nonterminal, in which case it represents the set of all terminals to which that nonterminal could expand. If the set consists of a single terminal the phrase “[lookahead ≠ terminal]” may be used.

[13:22:33.0000] 
devsnek: i don't think a plenary topic, but yes an issue

[13:22:44.0000] 
like doing `Array.caller` or `Array.arguments`

[13:23:06.0000] 
The grammar includes `[lookahead ≠ "let" "["]` in many places, but I’m unclear on what would make that valid. The quoted text seems to be saying that this should be `[lookahead ∉ { "let" "[" }]`

[13:23:09.0000] 
devsnek: oh hm, not sure about that part

[13:23:25.0000] 
i'm not sure if that exactly was the topic

[13:23:42.0000] 
but i'm pretty sure something weird like that

[13:24:05.0000] 
bathos: `if (let [x] = 1)`

[13:24:09.0000] 
er

[13:24:10.0000] 
for

[13:24:12.0000] 
not if

[13:24:17.0000] 
my rust habits are leaking in

[13:24:37.0000] 
I understand the intended effect, I’m referring to the notation

[13:24:50.0000] 
devsnek: it's okay, you're just excited for Devin's proposal, right

[13:24:56.0000] 
lol

[13:25:23.0000] 
bathos: `lookahead ∉ { "let" "[" }` means lookahead cannot be one of the elements in the set

[13:25:29.0000] 
There’s seemingly no allowance for `[lookahead ≠ terminal-sequence]`, only the set notation seems to permit its members to be sequences of terminals / nonterminals

[13:25:43.0000] 
devsnek: only if there is a comma

[13:26:19.0000] 
set members can be sequences, as occurs in several places and is mentioned in that quoted bit. Commas separate the sequences

[13:26:53.0000] 
oh you mean a single-itemed set of that production

[13:26:54.0000] 
hmm

[13:26:55.0000] 
(I mean, yes, it means lookahead cannot be one of the elements in the set. But that’s a set with one member)

[13:27:06.0000] 
`If the set consists of a single terminal the phrase “[lookahead ≠ terminal]” may be used.`

[13:27:20.0000] 
i think this is what you're looking for then

[13:27:47.0000] 
Right — but `let [` is two terminals.

[13:28:14.0000] 
It says the ‘shorthand’ is available when it’s just one.

[13:29:09.0000] 
I think maybe it should say ‘if the set consists of a single member’ or ‘if the set consists of a single sequence of terminals’

[13:29:21.0000] 
yeah the wording could be improved

[13:29:37.0000] 
(Example of sequences in the set notation here: https://tc39.es/ecma262/#prod-ExpressionStatement)

[13:29:41.0000] 
thankfully it's doing what it means to, so it's really just a little editorial thing

[13:30:20.0000] 
i would say `If the set consists of a single element the phrase “[lookahead ≠ element]” may be used.`

[13:31:26.0000] 
the rest of the paragraph does refer to "terminal sequence(s)" though

[13:31:35.0000] 
so I think it would be natural to carry that through

[13:31:48.0000] 
(er well, there are two such paragraphs that are very similar but yeah)

[13:32:24.0000] 
we should just have a link to a live web chat with waldemar

[13:32:27.0000] 
where he explains the grammar

[13:32:44.0000] 
heh, I'm sure he'd love that

[13:32:52.0000] 
but it's just a simple oversight, really

[13:32:54.0000] 
Yeah — I think either "element" or "terminal sequence" would work. I wasn’t sure if I was missing something or if it was a typo etc.

[13:34:08.0000] 
another thing I noticed while looking at this

[13:34:25.0000] 
I wonder if the font usage in https://tc39.es/ecma262/#sec-grammar-notation is really what it's meant to be

[13:34:46.0000] 
like

[13:34:51.0000] 
> Terminal symbols are shown in `fixed width` font, both in the productions of the grammars and throughout this specification whenever the text directly refers to such a terminal symbol.

[13:35:27.0000] 
er well hmm actually maybe it's not fixable

[13:35:29.0000] 
Yeah, that should be something like ‘literal’ terminals. Referenced terminals use italics like nonterminals do.

[13:36:04.0000] 
er at least I was focused on the fixed width font being different in the paragraph vs. the production

[13:36:16.0000] 
ah

[13:37:12.0000] 
but that's just that our  font and our  font are different, but both are at least fixed width, and the latter isn't choosable in body text

[13:37:20.0000] 
so I guess that's fine-ish

[14:14:59.0000] 
rkisling/devsnek — opened a PR for the description of the single-element shorthand: https://github.com/tc39/ecma262/pull/1828

[14:17:22.0000] 
shu: dunno if you saw my ping yesterday, but the changes to function arguments broke the scope a bit. i'm trying to figure out a fix but i'm not 100% sure what the intended behaviour is supposed to be

[14:17:38.0000] 
bathos: nice

[14:20:44.0000] 
devsnek: oh? i missed it, will look in a bit

[14:21:33.0000] 
shu: very quick example `(function(a, b = a) {})()`, `a` is created in `env`, but `env` is not attached to the current context, so in `b = a`, looking up `a` is a reference error

[14:51:01.0000] 
devsnek: isn't that example okay because env is passed in explicitly to IteratorBindingInitialization?

[14:51:26.0000] 
shu: it creates the bindings just fine

[14:51:34.0000] 
but the expression on the right hand side of an initializer

[14:51:38.0000] 
can not see the environment

[14:52:32.0000] 
ah, indeed that seems like a bug yes

[14:53:36.0000] 
good catch

[14:54:02.0000] 
step 2 for FDI needs to set both the LexicalEnvironment and the VariableEnvironment

[14:55:12.0000] 
like `calleeContext.LexicalEnvironment = env` after step 19?

[14:55:31.0000] 
well [[LexicalEnvironment]]

[14:55:34.0000] 
or however the spec notates it

[14:57:34.0000] 
i think it's one of those non-slot slots

[14:58:06.0000] 
so it'd just be "Set calleeContext's LexicalEnvironment to env"

[14:58:11.0000] 
seems to work in engine262

[14:58:46.0000] 
this whole section of the spec is very confusing

[14:59:30.0000] 
`(function(a = eval('var c = 1')) { return c })()` should this return 1 or throw an error

[15:00:41.0000] 
i thought the extra environment was to separate it so it should throw but maybe i have the wrong idea

[15:01:21.0000] 
that should return 1

[15:02:57.0000] 
from outer to inner, for a function with parameter expressions, the envs are:

[15:04:16.0000] 
1. FunctionEnv (holds vars introduced by direct eval in parameter expressions) -> 2. DeclarativeEnv (params, "arguments", etc) -> 3. DeclarativeEnv (body vars) -> 4. DeclarativeEnv (body lexicals)

[15:04:35.0000] 
during parameter evaluation, 1 is the context's VariableEnvironment and 2 is the context's LexicalEnvironment

[15:04:45.0000] 
during body evaluation, 3 is the VarEnv and 4 is the LexEnv

[15:04:52.0000] 
at least that's what it's supposed to be

[15:04:57.0000] 
i see

[15:05:59.0000] 
shall i prepare a PR or do you have one handy?

[15:06:08.0000] 
you probably should

[15:07:28.0000] 
will do

[15:07:45.0000] 
it's kind of weird how often `NOTE:`s are inlined into algs

[15:07:56.0000] 
seems like probably more than necessary

[15:07:59.0000] 
yeah, ecmarkup feature request

[15:08:15.0000] 
they at least shouldn't end up renumbering the alg steps

[15:08:58.0000] 
is there an existing one?

[15:09:03.0000] 
i'm still getting weird errors in engine262 and i'm not sure if they're spec bugs or engine262 bugs lol

[15:09:04.0000] 
https://gc.gy/45797934.png

[15:10:29.0000] 
devsnek: your second example should error

[15:10:36.0000] 
though that error doesn't make sense

[15:10:40.0000] 
that is a redeclaration error

[15:10:47.0000] 
maybe I should help out with ecmarkup stuff

[15:10:53.0000] 
so many things that could be done

[15:10:57.0000] 
shu: it's a runtime reference error

[15:11:05.0000] 
should it be a syntax error

[15:11:17.0000] 
the parameter 'a' is like a lexical binding, and the direct eval 'a' is trying to declare in the VarEnv, which is outer of the lexical env that contains the parameter 'a'

[15:11:23.0000] 
so when the direct eval runs it should be a SyntaxError

[15:11:28.0000] 
i see

[15:12:29.0000] 
shu: is that re-declaration check added in annex b

[15:13:26.0000] 
devsnek: no, that's just a regular redeclaration check afaik

[15:13:42.0000] 
it's the same semantics redeclaration wise as `let a; { var a; }`

[15:13:54.0000] 
i'm trying to see if my impl of EvalDeclarationInstantiation diverges

[15:14:19.0000] 
there is only one place where a var can be declared "over" an already declared lexical binding

[15:14:22.0000] 
i think...

[15:14:31.0000] 
which is the weird annex b catch block semantics

[15:14:37.0000] 
where you can have a var with the same name as the lexical catch binding

[15:17:54.0000] 
`let a; eval('var a')` throws a syntax error as expected

[15:21:12.0000] 
on function entry, there is a single environment that is both the VarEnv and the LexEnv

[15:21:43.0000] 
and then once you hit sloppy step with parameter expressions, you make a new env, set that as the LexEnv but leave the VarEnv alone

[15:21:54.0000] 
is that what you're doing?

[15:22:20.0000] 
i added a step after 19 that sets the VariableEnvironment and the LexicalEnvironment to env

[15:22:30.0000] 
should it just be the LexicalEnvironment

[15:22:47.0000] 
yeah, sorry, not both, just LexicalEnv

[15:23:02.0000] 
let me push the PR and you can see the diff, it's small

[15:23:50.0000] 
ey it works now

[15:26:05.0000] 
:+1:

[15:26:28.0000] 
i assume it should also throw in strict mode right

[15:27:36.0000] 
actually

[15:27:40.0000] 
no it does not

[15:27:48.0000] 
strict mode direct evals have their own var envs, vars cannot escape

[15:28:06.0000] 
i think test262 needs to flag some tests as strict only in that case

[15:28:29.0000] 
ah, i updated test262 for this, did i miss some?

[15:29:11.0000] 
uh language/expressions/arrow-function/eval-var-scope-syntax-err.js

[15:29:17.0000] 
language/expressions/async-generator/eval-var-scope-syntax-err.js

[15:29:21.0000] 
i think these are all generated

[15:29:49.0000] 
the description says "sloppy only"

[15:29:55.0000] 
yeah

[15:29:58.0000] 
should not run in strict mode

[15:30:04.0000] 
there's a flag for that?

[15:30:17.0000] 
yes by default all tests run in strict and sloppy mode

[15:30:23.0000] 
wat

[15:30:25.0000] 
lol

[15:31:03.0000] 
there are two flags

[15:31:06.0000] 
onlyStrict and noStrict

[15:41:44.0000] 
shu: how were you visualizing an inline note appearing without using a list item numeral?

[15:42:37.0000] 
i assume like in the html spec

[15:43:00.0000] 
do they have the full note styling injected into the steps?

[15:43:07.0000] 
rkirsling: i have not thought too much about it, maybe a differently colored box with the same indent as the step, but without a numeral?

[15:43:16.0000] 
right fair enough

[15:43:21.0000] 
https://gc.gy/45799992.png

[15:43:28.0000] 
cool

[15:43:47.0000] 
we could get fancy like give notes their own separate ordinal

[15:44:05.0000] 
i propose footnotes

[15:44:21.0000] 
well I would leave that part for after https://github.com/tc39/ecma262/issues/1825 I guess, but for now, I might just address the cases where either (1) there's a NOTE tacked onto the end of a line or (2) the final step is a NOTE that applies to the whole alg

[15:44:23.0000] 
(/s)

[15:44:23.0000] 
i think i like them inline actually

[15:44:35.0000] 
yeah i was kidding, footnotes would be terrible

[15:44:42.0000] 
having to jump to the bottom of an 800 page document

[15:44:50.0000] 
'cause those are the only two cases that I find problematic

[15:45:09.0000] 
"for footnotes, please purchase Volume: Footnotes"

[15:45:15.0000] 
lol

[15:45:35.0000] 
"if Ecma were an academic publishing org"

[15:46:01.0000] 
can we just copy everything the wasm spec does

[15:46:05.0000] 
visually i mean

[15:46:10.0000] 
writing our documentation in mathjax would suck

[15:46:15.0000] 
like, use tex fonts?

[15:46:24.0000] 
wasm is real purty

[15:46:30.0000] 
shu: yes

[15:46:35.0000] 
but yeah mathjax requires a multipage spec

[15:47:03.0000] 
otherwise it's "brb gonna render 1200 pages of TeX real quick and get back to you"

[15:48:11.0000] 
i have a fun "knuth" theme for wikipedia

[15:49:11.0000] 
https://gc.gy/45800345.png

[15:49:21.0000] 
no we are the people's spec

[15:49:26.0000] 
none of them snooty tex type here

[15:50:15.0000] 
https://gc.gy/45800413.png

[15:51:59.0000] 
lol

[15:52:13.0000] 
shu: actually I think there is truth to that though

[15:53:48.0000] 
if we (along with most web specs) don't get by with normal web rendering then it seems a bit like blatant non-dogfooding

[15:54:14.0000] 
mathml would be a different story

[15:55:28.0000] 
hmm, there are a total of only four notes that bother me

[15:55:38.0000] 
*inline notes

[15:56:21.0000] 
three are on the same line as a normal alg step, one (well, maybe two) is a final inline note that should be non-inline

[15:57:04.0000] 
but I still hesitate slightly because step 14 at the end of https://tc39.es/ecma262/#sec-runtime-semantics-caseblockevaluation is tricky

[15:57:34.0000] 
well nah I suppose that can just be raised

[15:57:43.0000] 
these are effectively line comments after all

[15:58:14.0000] 
that note is terrifying


2020-01-04
[16:01:28.0000] 
rkirsling: ftfy https://gc.gy/45801085.png

[16:01:46.0000] 
hahaha

[16:01:52.0000] 
i like that yeah

[16:01:58.0000] 
can you do flames

[16:02:05.0000] 
lol

[16:02:08.0000] 
maybe some comic sans too

[16:02:39.0000] 
yes

[16:38:42.0000] 
meh https://github.com/tc39/ecma262/pull/1831


2020-01-05
[07:24:50.0000] 
i know the realms shim is already a thing, but has the ability to create new agents ever been discussed?

[07:25:30.0000] 
in theory completely sandboxed off, would have to use structured cloning or something to share data

[09:04:25.0000] 
devsnek: you'd need to have structured cloning in the language first

[09:04:49.0000] 
ljharb: at the same time probably

[09:04:58.0000] 
I'm not so worried about the specifics

[09:05:01.0000] 
that seems like a massive proposal on its own

[09:05:52.0000] 
probably

[09:09:16.0000] 
ljharb: it's kind of just the worker spec but with less web

[10:26:15.0000] 
Why cloning? Only need that for communication between agent clusters

[10:26:37.0000] 
Shared memory is available between agents

[10:32:11.0000] 
annevk: yeah and shared memory


2020-01-06
[16:10:11.0000] 
how to learn ecmascript?

[17:38:57.0000] 
hey TabAtkins, how'd it come to be that Bikeshed notes put "Note:" in the body text instead of "NOTE" in a ::before?

[19:39:05.0000] 
rkirsling: So they'll show up in a Ctrl-F

[19:43:31.0000] 
TabAtkins: oh. I guess my real question was why "Note:" vs. "ISSUE 1" / "EXAMPLE 1" / etc.

[19:45:06.0000] 
just looking at improving our note styling and figured I'd take a page out of your book to the extent that it makes sense

[19:45:09.0000] 
NOTE 1

[19:45:28.0000] 
i don't think numbering them helps that much

[19:45:36.0000] 
they're not normative

[19:47:18.0000] 
sure I'm not trying to say what anybody else should do, but we do indicate "NOTE" and I don't know that I care to change that part

[19:47:20.0000] 
(https://github.com/tc39/ecma262/issues/1825#issuecomment-570971879)

[19:47:57.0000] 
Yeah we've never numbered notes, just because.


2020-01-07
[19:13:54.0000] 
shu: i think the tests involving classes are wrong

[19:14:00.0000] 
since class bodies are always strict

[19:35:01.0000] 
devsnek: yes, patrick pointed that out

[19:35:22.0000] 
devsnek: i don't know how to do the test262 generation so the flag only propagates to a subset of generated tests

[19:36:46.0000] 
i believe its make.py

[19:37:56.0000] 
like edit the script to special case that one template?

[19:38:05.0000] 
i'll leave that to one of the bocoup folks if so

[19:38:23.0000] 
oh are you saying it should skip generating tests for classes?

[19:38:29.0000] 
yeah i dunno how to do that :P

[19:39:05.0000] 
right, all the function forms are generated from that one template

[19:39:14.0000] 
which spectranaut set up

[19:40:41.0000] 
interesting

[19:41:38.0000] 
i guess i'll blacklist the tests for now

[21:15:45.0000] 
in the short term tho, those tests can just be deleted, no?

[21:15:52.0000] 
the bug with the generation code is separate

[08:31:23.0000] 
ljharb: yes, they could be

[08:31:44.0000] 
ljharb: whoever runs make.py next would just have to know what to delete though

[10:25:22.0000] 
shu: ah gotcha

[10:25:38.0000] 
shu: seems urgent tho to remove the signal that implementors should start making this change in class bodies?

[10:25:56.0000] 
sure

[13:06:18.0000] 
ljharb: spectranaut is working on it, probably should land later today: https://github.com/tc39/test262/pull/2465

[13:12:56.0000] 
awesome

[13:29:50.0000] 
can someone confirm for me what `new Date('-109252-01-31T11:59:59.708Z').getSeconds()` should print out according to the spec?

[13:30:11.0000] 
(chakra, spidermonkey, and new v8 print one thing; jsc, xs, and old v8 print another thing)

[13:30:37.0000] 
(also new spidermonkey ← and old spidermonkey →)

[13:53:31.0000] 
by new/old do you mean both of those changed that behavior fairly recently?

[13:56:58.0000] 
for v8, it changed in node 10

[13:57:11.0000] 
i haven't spelunked for spidermonkey yet

[13:57:32.0000] 
so i assume either that a) there's a bug in half of the engines, or b) the spec changed and only half of the engines have caught up

[13:59:37.0000] 
ljharb: pretty sure it should be 59

[13:59:39.0000] 
guessing the latter

[14:00:08.0000] 
devsnek: that's what i'd assume but then that means v8 and spidermonkey both *changed* to have the bug

[14:00:15.0000] 
(which is that it prints out 1)

[14:00:29.0000] 
oh wow

[14:00:43.0000] 
i can see the logic for both; it's :59, so it's 59; but it's negative, so it's 60 - 59

[14:00:59.0000] 
but i haven't dove into the spec text yet and was hoping someone with more datetime experience could

[14:01:03.0000] 
the alternative is that i implemented date wrong in engine262

[14:01:06.0000] 
which is possible

[14:01:23.0000] 
i'm happy to file all the engine bugs, and/or fix es5-shim :-) i just need to know what's "correct"

[14:02:01.0000] 
i'm reading through it rn

[14:02:24.0000] 
<3

[14:05:21.0000] 
ok yeah it should be 59

[14:05:36.0000] 
assuming a system timezone of utc

[14:06:15.0000] 
assuming any timezone, no?

[14:06:17.0000] 
ljharb: i think you can verify that by explicitly overriding the TZ env variable to "UTC"

[14:06:31.0000] 
oh hm

[14:06:40.0000] 
when i do `TZ=UTC eshost tmp.js` then they all print 59

[14:06:49.0000] 
otherwise all the ones i'm talking about print 1

[14:06:58.0000] 
why would the timezone's hour offset affect seconds on a negative date?

[14:07:19.0000] 
something something intl data i assume

[14:08:02.0000] 
i don't know much about how that stuff works

[14:08:33.0000] 
cc leobalter for intl question?

[14:09:15.0000] 
i think in the spec this is "LocalTZA"

[14:09:20.0000] 
which is an offset in milliseconds

[14:09:28.0000] 
so it could adjust by something other than hour chunks

[14:10:18.0000] 
and why would a bunch of timezones have a LocalTZA that causes only *negative* dates (based on es5-shim's tests) to be the inverse amount of seconds

[14:11:59.0000] 
in -109260, the king of earth decided to give each town a unique timezone, each offset by one second

[14:22:36.0000] 
so it seems like i need to confirm that a value of 59 isn't overridden by intl


2020-01-08
[09:52:08.0000] 
new rule: any tc39 proposals seeking advancement must henceforth be presented in rap form https://twitter.com/mathias/status/1214966958799671298

[09:57:41.0000] 
nice work

[09:58:23.0000] 
I have a feeling if you establish that rule it's going to be 90% "hey my name is X and I'm hear to ~say~ propose ..."

[10:59:23.0000] 
am i in the 90s

[11:02:35.0000] 
parents just don't understand

[11:10:18.0000] 
we could also require music videos instead of slide decks

[11:22:16.0000] 
I can't rap but I'd be down for a musical number

[11:22:34.0000] 
(like the TCO thing lol)

[12:11:30.0000] 
realms proposal seems well-suited to interpretive dance

[12:14:04.0000] 
i move my body to demonstrate the boundaries of my compartment, this scarf represents a membrane

[13:29:25.0000] 
feat lil' Jessie

[13:46:52.0000] 
robpalme: well played


2020-01-09
[17:37:42.0000] 
whoa

[17:37:59.0000] 
links to `thisTimeValue` in the spec hard-change the domain to tc39.github.io

[19:52:08.0000] 
what on earth

[19:52:53.0000] 
everything listed in here hard-links to tc39.github.io/ecma262 and everything else keeps the current page

[19:52:54.0000] 
https://github.com/bterlson/ecmarkup/blob/master/es6biblio.json

[19:54:04.0000] 
meaning that clicking `thisTimeValue` or `thisBooleanValue` always reloads the page

[19:54:31.0000] 
but `thisStringValue`, which isn't in there, is just fine

[19:58:59.0000] 
ouch

[19:59:27.0000] 
rkirsling: i wonder if they're in there for proposals, to link *those* properly

[20:00:23.0000] 
ohhh

[20:01:08.0000] 
which means three things; thisStringValue *should* be in there; the domain needs to be updated for all of them; and also when running on the spec itself, those links should be relative, not absolute

[20:02:09.0000] 
agreed...

[20:02:54.0000] 
but also i'd suspect that ideally, that "biblio" thing shouldn't be embedded in ecmarkup but should be fetched (at publish time if not at runtime) from a build artifact of the spec itself

[20:03:16.0000] 
yeah :-/

[20:04:23.0000] 
are there other things in that json that are linked incorrectly in the actual spec?

[20:04:30.0000] 
rkirsling: in terms of a short term fix: if there's any chance ecmarkup can override those biblio things via a CLI flag or something, or disable it, that'd be ideal

[20:04:52.0000] 
right, yeah

[20:05:15.0000] 
not sure if there's anything that's like, mispointed, say

[20:05:26.0000] 
well, that has an absolute link but shouldn't

[20:05:29.0000] 
but it's surely possible since the last sync was for es2017

[20:05:44.0000] 
right, but i'm wondering if all the things that were *in* es2017 are linked in this wrong way

[20:06:00.0000] 
or if not, then why is thisTimeValue special

[20:09:54.0000] 
I believe the answer is no; only those two have aoids

[20:10:06.0000] 
I don't actually know what an aoid is

[20:10:29.0000] 
abstract operation id

[20:10:52.0000] 
ah cool

[20:11:08.0000] 
err sorry

[20:11:22.0000] 
that was not specific enough, what I meant to say is

[20:11:44.0000] 
those are the only two ``s with an `aoid`

[20:11:55.0000] 
other elements are fine somehow(???)

[20:12:01.0000] 
ah, so maybe it's just an ecmarkup bug with dfns that have aoids?

[20:12:09.0000] 
can you file that on ecmarkup? :-)

[20:14:04.0000] 
thisStringValue also has dfn-with-aoid

[20:14:52.0000] 
jmdyck: right, but ecmarkup's biblio.json hasn't been updated since es2017, and thisStringValue wasn't moved to be a proper abstract op until es2018 iirc

[20:15:15.0000] 
this is gonna be hard to know because I don't know how that JSON is generated

[20:15:19.0000] 
there's like 5 or 6 thisFooValue's, and in es2017 and earlier, i think only thisTimeValue and thisBooleanValue were proper abstract ops, markup-wise

[20:15:28.0000] 
yup, 6

[20:15:42.0000] 
I don't understand why ThisXyxValue ops are special at all

[20:16:00.0000] 
devsnek: they shouldn't be anymore

[20:16:10.0000] 
devsnek: in es2017 and earlier tho, they were

[20:16:11.0000] 
they start with a lowercase

[20:16:12.0000] 
like, I think something causes the _links_ to `thisTimeValue` to get "namespaced" with tc39.github.io/ecma262

[20:16:21.0000] 
devsnek: true, that's the only thing that's unique

[20:16:24.0000] 
well, they're fairly special in that they don't have their own clause

[20:16:54.0000] 
but presumably the trigger point is not at the reference site but at the definition site

[20:17:05.0000] 
ugh

[20:27:35.0000] 
it's baffling because by staring at the JSON, it looks like RepeatMatcher should have the exact same problem

[20:27:49.0000] 
hence my thinking that  is problematic in particular

[20:28:32.0000] 
but if, running locally here, the *only* thing affecting that behavior is the JSON

[20:28:50.0000] 
then why is the problem not reflected in the JSON...

[21:38:58.0000] 
huh

[21:40:07.0000] 
strangely enough, if I run `ecmarkup` with `--biblio` to produce the new copy, then drag that over to node_modules/ecmarkup and rebuild using it

[21:41:20.0000] 
then (1) the JSON is up-to-date and has tc39.es in it, of course, but (2) instead of *more* things hard-linking to tc39.es, everything seems to just use my local copy

[21:41:36.0000] 
no idea why that is but maybe we can just update ecmarkup then

[22:01:19.0000] 
rkirsling: updating the build process in 262 is, atm, much easier than updating ecmarkup

[22:07:29.0000] 
ljharb: that's understandable, but there isn't a way to ignore node_modules/ecmarkup/es6biblio.json

[22:07:58.0000] 
rkirsling: the build script could `mv` the new copy into node_modules and then rerun it

[22:09:08.0000] 
that is true but I think it would double the build time

[22:10:21.0000] 
¯\_(ツ)_/¯ it happens in ci

[22:10:33.0000] 
and it's a temporary workaround anyways

[22:47:57.0000] 
hrm, I'll pick this up again tomorrow

[23:02:44.0000] 
ljharb: sorry for answering your question late, but those unexpected getSeconds() results derive from the fact that the time zone database has fractional-hour offsets for so-called "local mean time" of time zones before their official introduction. US time zones were introduced in 1883 (https://www.timeanddate.com/time/zone/usa#the ), so any dates before that will have offsets that are not necessarily an integer number of quarter-hours

[23:04:47.0000] 
gibson042: wow ok, so that behavior is *correct*?

[23:05:12.0000] 
yep, continget upon tzdata

[23:05:28.0000] 
woof, ok

[23:06:33.0000] 
a kind soul has exposed 2019c as npm packages, so you can actually explore it fairly conveniently: https://runkit.com/embed/dv5lqhvkipy7

[23:07:28.0000] 
e.g., America/Los_Angeles was +07:52:58 until 1883-11-18T12:07:02.000 local time

[23:07:40.0000] 
so it sounds like probably not having those fractional offsets is compliant with 262, but 402 requires applying them?

[23:08:02.0000] 
it should be independent of 402

[23:08:34.0000] 
so in 262, it's hand-wavy "implementation-dependent" stuff, or is there an explicit part about it?

[23:09:05.0000] 
the former: https://tc39.es/ecma262/#sec-local-time-zone-adjustment

[23:09:33.0000] 
"offset of the local time zone from UTC measured in milliseconds at time represented by..."

[23:10:15.0000] 
in reality, that's a tzdb consultation

[23:11:23.0000] 
thanks, that makes sense

[23:13:46.0000] 
oh wow, as soon as my head hit the pillow the situation with that biblio thing clicked

[23:15:15.0000] 
ljharb: if it's literally a "bibliography" for use in something that's *not* 262 (i.e. a spec proposal), then the current issue we're seeing I think amount to viewing the current spec as "not 262" by virtue of it not being ES2017

[23:15:56.0000] 
hence up-to-date JSON and empty JSON should have the same effect

[23:16:31.0000] 
rkirsling: aha

[23:16:41.0000] 
so we should be able to do your "skip biblio for 262 itself" by `echo "{}" > node_modules/ecmarkup/es6biblio.json`

[23:16:45.0000] 
awesoe

[23:16:49.0000] 
let's do that in 262 as a workaround

[23:17:02.0000] 
👍 will PR tomorrow

[23:17:20.0000] 
woot, ty

[12:20:04.0000] 
is there a particularly good reason that bigint literals are allowed as property names in object literals?

[12:21:16.0000] 
I guess all numeric literals were already allowed (not just decimal)

[12:21:33.0000] 
feels like mostly gratuitous implementer pain, tho

[12:39:59.0000] 
is it that difficult to implement? bigint literals are a distinct token so it should be straightforward

[13:06:22.0000] 
it's not absolutely terrible, but we're having to do some extra effort to handle it now

[13:06:44.0000] 
I'm not sure if that extra effort is from careless oversight or what, not following the bug closely enough

[13:09:52.0000] 
my guess is that the good reason would have been needed to deviate from the precedent, but no idea

[13:10:35.0000] 
They aren’t a distinct token — NumericLiteral is the token and it’s the static semantics of NumericValue that make the distinction

[13:10:59.0000] 
bathos: i mean in implementations

[13:11:10.0000] 
implementations can and likely do realize it as a distinct token, yeah

[13:12:26.0000] 
what makes it undesirable for them to be legal there, though?

[13:12:56.0000] 
they already have three forms

[13:13:11.0000] 
identifier, numeric literal, and computed

[13:14:26.0000] 
oh and functions

[13:14:35.0000] 
functions?

[13:15:03.0000] 
`({ f() {} })`

[13:15:11.0000] 
methods i guess

[13:15:21.0000] 
isn’t that just identifier?

[13:15:54.0000] 
e.g. `({ 1() {} })` is also legit

[13:16:01.0000] 
1 isn't an identifier

[13:16:29.0000] 
right, I mean both are just uses of LiteralPropertyName

[13:16:52.0000] 
(iirc)

[13:17:55.0000] 
anyway my point is that there's already a lot of stuff ther

[13:17:57.0000] 
there*

[13:18:11.0000] 
i.e. in `({ XXX() {}, XXX: 1 })`, the XXX part is the property name bit which is common to both productions

[13:18:38.0000] 
yeah, I suppose I’d have thought disallowing one of the forms of numeric literal is ‘more’ rather than ‘less’ stuff to account for

[13:20:38.0000] 
it looks like both V8 and Spidermonkey don’t allow bigint property names actually

[13:22:04.0000] 
so changing it in the spec to match that ought to be safe at least

[13:46:20.0000] 
SpiderMonkey does allow it as of a super-recent (i.e. measured in hours) bugfix

[13:46:50.0000] 
I was just trying to do the step back and consider whether this is sensible thing, that it does not appear anyone else had done

[13:47:48.0000] 
given all the existing silliness that is accepted -- prefixes, fractional parts, separators, yadda yadda -- excluding just bigints is probably not obviously justified

[13:55:02.0000] 
I would feel surprised as a user if it threw, that's for sure

[13:55:18.0000] 
`({ 0x20000000000001: 1, 0x20000000000001n: 2 })` :)

[13:55:44.0000] 
the "n" is for "no"

[13:56:18.0000] 
I smell an eslint rule

[14:00:41.0000] 
jmdyck: can you write a proxy such that it behaves exactly like an array

[14:00:59.0000] 
i'm pretty sure you can

[14:01:02.0000] 
setting aside Array.isArray, presumably

[14:01:10.0000] 
well the argument is about how IsArray works

[14:01:23.0000] 
if something is behaviourally identical to an array exotic object

[14:01:27.0000] 
is it an array exotic object

[14:16:36.0000] 
doesn't IsArray defer to the proxy's target?

[14:16:56.0000] 
so then, only if the proxy's target is an array

[14:17:33.0000] 
rickbutton: the question is like, if something behaves exactly like an array

[14:17:42.0000] 
should IsArray be true or false for it

[14:18:56.0000] 
oh i see

[14:20:39.0000] 
i'd say there's a difference between an array exotic object

[14:20:44.0000] 
and something that happens to behave like one

[14:54:35.0000] 
formally, all IsArray establishes is a single, useless fact: that the object has a length property which is unconfigurable (though it does not guarantee it is a valid length)

[14:55:25.0000] 
the proxy-passthrough behavior kills everything else it could have told you

[14:55:50.0000] 
since that’s the sole thing that a proxy whose target IsArray could not change

[14:57:24.0000] 
@devsnek the spec agrees with you at least, since IsArray itself requires that distinction to exist


2020-01-10
[16:53:15.0000] 
whether or IsArray is useful or not as it stands isn't really material, the question is more like

[16:54:11.0000] 
if we want observable behavior to be able to depend on "if obj is a Foo exotic object", that check should be decidable

[16:54:41.0000] 
i am very surprised this is contentious

[16:54:46.0000] 
same

[16:55:22.0000] 
though i am heartened by allen chiming in in agreement

[17:07:43.0000] 
devsnek: (re 3 hrs ago): I wondered that myself. Here's another: can you write a proxy that behaves exactly like an ordinary object?

[17:08:10.0000] 
that i know you can do

[17:09:58.0000] 
ok, then it's a wider issue than just "X is a Foo exotic object"

[17:10:29.0000] 
how so?

[17:10:59.0000] 
the spec has visibility into a Proxy that behaves like an ordinary object in evaluation and an ordinary object

[17:25:18.0000] 
If the semantics of "X is a Foo object" were "X exhibits behavior that conforms to the spec for Foo objects" and some alg said "If X is an ordinary object, ..." then that would accept a proxy (or some other non-standard exotic) that's behaving like an ordinary, which we presumably don't want, so that'd be another argument against me. (Except that I don't think the spec ever says anything like "If X is an ordinary object". Ther

[17:25:18.0000] 
sertions, but I'm guessing they wouldn't be a problem.)

[17:26:58.0000] 
ah

[17:27:31.0000] 
yes i can't say there are any special checking for ordinary objects, only exotics

[17:34:25.0000] 
in fact, it's a little odd that the spec *does* have "If X is a Foo exotic object". Places where the MOP doesn't entirely abstract away different behaviors

[17:35:10.0000] 
that i agree with

[17:35:28.0000] 
i'd rather see abstract operations, something concrete

[17:38:15.0000] 
There's not a huge number of them; it might be do-able.

[20:08:39.0000] 
i feel like we need some sort of strategic initiative to spend time improving our spec tooling, consistency, etc

[20:08:44.0000] 
like just pause proposals for a few months

[20:09:14.0000] 
lol I would support that so hard

[20:09:47.0000] 
i started to outline what i think would be a cool syntax for defining spec

[20:10:02.0000] 
(would give me some time to work on ecmaspeak)

[20:10:03.0000] 
i don't know how to write vim highlighting files though so it looks very drab

[20:10:12.0000] 
is ecmaspeak your spec evaluator

[20:10:39.0000] 
more like linter so far, but yeah

[20:11:37.0000] 
what's your cool syntax look like?

[20:13:47.0000] 
(and do you think it has a hope of being adopted, or is this just for fun?)

[20:14:01.0000] 
https://gc.gy/46334636.png

[20:14:16.0000] 
it's still in the "rough sketch" stage

[20:15:04.0000] 
i need to figure out a better sigil for variables

[20:15:27.0000] 
is it completely markdown-ish, or are there html tags elsewhere?

[20:15:37.0000] 
there are not any html tags yet

[20:15:49.0000] 
i should say, the goal is not to approximate markdown

[20:16:10.0000] 
the dash was chosen because typing `1.` each time is awkward and visually confusing

[20:16:36.0000] 
i chose it over `*` because `*` is often rendered at the top of the line

[20:17:04.0000] 
I'm also trying to make sure the structure is really consistent so it can be parsed

[20:18:13.0000] 
is there a way to distinguish (what in the current spec is) an  from a  from a ?

[20:19:01.0000] 
i haven't gotten to ol/ul yet

[20:25:06.0000] 
jmdyck: i also had an idea of making it much more like actual code, but i'm not sure it if would catch on

[20:25:31.0000] 
just the emu-alg stuff, you mean?

[20:25:58.0000] 
yeah

[20:26:53.0000] 
it would render out mostly the same though

[20:26:57.0000] 
actual code in an actual programming language?

[20:27:10.0000] 
not in a current programming language

[20:27:14.0000] 
just a very regular syntax

[20:27:17.0000] 
 just actual code in a hypothetical language

[20:27:19.0000] 
where you use like `==` instead of "is"

[20:27:46.0000] 
https://gc.gy/46335461.png

[20:27:56.0000] 
notes could be // comments or something

[20:28:04.0000] 
much easier to edit

[20:28:13.0000] 
and if we render it right, much more regular patterns when reading

[20:31:38.0000] 
You're saying that would render out mostly the same as currently? E.g., the "} else {" would render as "Else," ?

[20:31:46.0000] 
yes

[20:32:17.0000] 
my thinking is

[20:32:26.0000] 
the build tooling would parse it completely, understand it, validate it

[20:32:32.0000] 
and then with all that knowledge of the structure

[20:32:39.0000] 
we can output nice human readable stuff

[20:33:19.0000] 
It's possible, but spec-authors might find the difference confusing.

[20:33:33.0000] 
true

[20:33:53.0000] 
there are downsides to everything tbh

[20:33:54.0000] 
e.g., see something in rendered spec, want to find correponding thing in source.

[20:34:02.0000] 
right now the spec is so horrid to edit

[20:34:17.0000] 
that actually might not be as hard as you think

[20:34:42.0000] 
rendered spec can retain links to the exact line/column of the source

[20:35:04.0000] 
well, i don't find the current spec horrid to edit, so who knows what I'd find hard.

[20:35:13.0000] 
i mean relatively

[20:35:21.0000] 
like think how easy it is to edit some python code

[20:35:32.0000] 
compared to how easy it is to edit some es spec logic

[20:36:00.0000] 
feels about the same to me

[20:36:10.0000] 
ok maybe a language that doesn't have significant whitespace

[20:41:23.0000] 
but again: do you think it has a hope of being adopted, or is this just for fun?

[20:41:38.0000] 
either way its for fun

[20:41:42.0000] 
but if i got something seriously working

[20:41:52.0000] 
and people liked it

[20:41:57.0000] 
if it were adopted, that'd be a huge diff and a ton of merge conflicts for in-flight PRs.

[20:42:02.0000] 
yeah

[20:42:19.0000] 
and all the git history would be lost

[20:42:34.0000] 
well, not lost, but harder to see

[20:42:47.0000] 
i'm also looking into ways to manually reattribute the history

[20:42:51.0000] 
(e.g., in a 'blame')

[20:43:03.0000] 
but i don't think i can parse the current spec with enough regularity to map the blames

[20:44:43.0000] 
not sure what you mean there. Attributing chunks of the new spec to the commits that were responsible for the corresponding chunk of the old spec?

[20:44:56.0000] 
yeah

[20:45:03.0000] 
like creating fake commit history

[20:45:09.0000] 
is that even theoretically possible?

[20:45:09.0000] 
with the same author information and stuff

[20:45:13.0000] 
yeah

[20:45:18.0000] 
its just difficult

[20:45:28.0000] 
ok, i think i get it now.

[20:45:53.0000] 
the whole history?

[20:46:01.0000] 
no just one layer of indirection

[20:46:31.0000] 
don't know what that means in this context

[20:46:36.0000] 
you'd end up looking at the current spec for anything more than one commit back

[20:46:41.0000] 
from whenever we rewrote it

[20:47:03.0000] 
its hard to describe

[20:47:28.0000] 
but would 'blame' work?

[20:47:46.0000] 
sort of

[20:47:53.0000] 
basically it would look like

[20:47:59.0000] 
you click blame on the rewrite

[20:48:25.0000] 
and you see something on some line like "xyz: blah blah blah "

[20:48:33.0000] 
basically a fake placeholder commit

[20:48:42.0000] 
that just targets those lines

[20:48:49.0000] 
so that the blame is in the correct spot

[20:51:09.0000] 
I think I'd need to see a few lines from the current blame (involving a few different commits) and then the corresponding lines from the new blame. (Not that I'm asking for it now, just a suggestion if you want to propose it.)

[20:53:02.0000] 
yeah i would figure it all out first


2020-01-12
[12:58:23.0000] 
did anybody create an issue for the Table 48 spillage?

[13:00:21.0000] 
(I think the answer is no; I wanted to make a fix for it but I'm baffled as to what the fix should be)

[13:10:40.0000] 
no

[13:18:13.0000] 
k, on it

[13:47:37.0000] 
guess I came up with a simple solution while writing up the issue, as one often does

[13:47:38.0000] 
https://github.com/tc39/ecma262/issues/1843

[13:59:42.0000] 
ljharb: would you want the CSS to be based on #table-42 though? seems kind of dangerous for maintainability... I'd rather have it restricted to emu-tables inside emu-notes at that rate. (it doesn't apply unless the screen width is encroaching, but when it is, it's kind of nice that even tables that do fit can sometimes accommodate a bit further)

[14:00:37.0000] 
(accommodate when you shrink your window such that they just don't fit)

[14:04:00.0000] 
rkirsling: i don't have a specific solution in mind, but in general i think code shouldn't wrap

[14:05:05.0000] 
for now, I'm gonna put up a PR that restricts to notes because it's the best suggestion I've got

[14:05:13.0000] 
it's fine if we go another way


2020-01-13
[16:28:44.0000] 
you could give #table-42 a better id.

[16:34:26.0000] 
as long as oldids works, that's a good improvement too

[16:36:15.0000] 
appears to. E.g. table-4 is an oldid and https://tc39.es/ecma262/#table-4 still works

[16:37:40.0000] 
slightly unfortunate that the oldid anchor is *after* the caption

[16:38:44.0000] 
ugh

[16:39:19.0000] 
just noticed Table 8 is overflowing the tiniest bit too on my screen thanks to SharedArrayBuffer.prototype

[16:40:20.0000] 
and I apparently don't know how to "break on punctuation"

[16:41:42.0000] 
I think ljharb's plan would do away with the .prototype rows (among others), so maybe not worth bothering about?

[16:41:57.0000] 
omg HTML does have TeX's ~ thing now?!

[16:42:00.0000] 
> The  element is a "word break opportunity" meaning a long word that would normally cause an annoying overflow issue could be told that it's ok to break at a certain point.

[16:42:09.0000] 
that's awesome

[16:42:30.0000] 
oh okay if there's another solution in the works then we can just forget about that one

[16:43:12.0000] 
which plan?

[16:43:57.0000] 
plan re %Foo.bar% intrinsics

[16:44:05.0000] 
(oh oops I think TeX's means "don't break here" but still.)

[16:46:38.0000] 
ljharb: https://github.com/tc39/ecma262/pull/1376#issuecomment-454166939

[16:48:43.0000] 
oh right

[16:48:57.0000] 
thanks for the reminder :-p

[16:49:40.0000] 
all those irons in the fire


2020-01-16
[10:04:50.0000] 
has anybody else often found themselves wishing Promise.all’s signature were (iterable, mapFn), like Array.from? Has that been proposed or discussed in the past?

[10:10:31.0000] 
bathos: you can already map it in the callback

[10:10:55.0000] 
or do you mean mapping the iterable before Promise.all uses it

[10:11:17.0000] 
cuz that's more generally represented by the iterator methods proposal

[10:11:55.0000] 
Before it uses it, yes. And yeah, iterator methods would address it.

[12:27:02.0000] 
nice https://gc.gy/46911421.png

[12:27:50.0000] 
devsnek: https://github.com/tc39/ecma262/issues/1812

[12:28:04.0000] 
lol

[12:28:17.0000] 
i'm thinking of opening a pr

[12:44:38.0000] 
and rob someone of their good first patch?

[12:50:30.0000] 
i mean

[12:50:42.0000] 
if it was picked up within a month that seems reasonable

[13:00:39.0000] 
good to go then.

[13:01:11.0000] 
ljharb: how often does ecma262 get first prs these days?

[13:13:12.0000] 
jmdyck: not super often

[13:13:21.0000] 
it's fine to pick up after a little while

[13:13:33.0000] 
but you two's resources are likely more effective on harder problems :-)


2020-01-17
[17:51:51.0000] 
Is there any discussion about adding functions to iterator?

[17:51:52.0000] 
Just like in other languages, that might be useful in stream like operation. E.g.

[17:51:52.0000] 
iterator.filter(odd).map(plusOne).collect()

[17:57:07.0000] 
jackworks: maybe this?: https://github.com/tc39/proposal-iterator-helpers

[17:59:35.0000] 
Cool I like it, thanks!

[17:59:46.0000] 
np

[15:01:11.0000] 
ljharb: are the ecmarkup changes not reflected in ecma262's rendering until its next merge?

[15:02:09.0000] 
jmdyck: it requires an npm publish of ecmarkup, and *then* an ecma262 build

[15:02:51.0000] 
you could push an empty commit

[15:02:56.0000] 
but that seems dirty

[15:03:14.0000] 
i can also just click "rebuild" on travis, once it's published

[15:03:23.0000] 
npm publish permissions haven't been granted yet

[15:03:35.0000] 
i've had github permissions for like, 20 minutes tho, relax :-)

[15:07:23.0000] 
exciting to see stuff gettin' merged anyway

[15:41:26.0000] 
jmdyck: ok, rebuilding now

[15:47:44.0000] 
rkirsling: jmdyck devsnek should be freshly rebuilt now

[15:49:59.0000] 
schweet


2020-01-18
[16:01:15.0000] 
yay

[16:05:21.0000] 
right now Iterator.from does OrdinaryHasInstance(%Iterator%, iterator)

[16:05:36.0000] 
would it be reasonable to do OrdinaryHasInstance(this value, iterator)

[16:05:39.0000] 
for subclassing

[16:17:10.0000] 
nvm scratch that

[16:33:21.0000] 
y'all ever seen this https://github.com/pgbovine/OnlinePythonTutor

[16:33:40.0000] 
ignore python in the name

[16:33:41.0000] 
it runs js too

[12:13:05.0000] 
Hello.

[12:13:31.0000] 
I have submitted an idea on discourse, namely "Optional named parameters".

[12:13:48.0000] 
Could you please have a look, and share your views?

[12:14:02.0000] 
The link to the idea is: https://es.discourse.group/t/optional-named-parameters/198

[12:38:50.0000] 
acagastya: seems like it should just create a split

[12:38:53.0000] 
in the ecosystem i mean

[12:39:05.0000] 
between people who use objects for optional params and people who use named args

[12:40:38.0000] 
also the syntax you proposed is already valid syntax

[13:16:02.0000] 
While it is "valid", it does not work the way one would expect it to.

[13:16:31.0000] 
Maybe, instead of '=', ':' or ':=' would be another option.

[13:26:11.0000] 
`:=` to me suggests Define semantics

[13:26:38.0000] 
acagastya: also, function arg names are really an implementation detail that's not visible outside the function. how would you know what names to pass?

[13:43:19.0000] 
As the proposal mentions, since it is optional, those who want to make use of the order of parameters can still use it.

[13:44:46.0000] 
And for those who have access to the function and know the parameter values, say someone's own module/library, instead of keeping in mind the order, they can go with the parameter names.

[13:45:05.0000] 
then you get into swift problems

[13:45:14.0000] 
swift has the ability to create argument name aliases

[13:45:24.0000] 
because otherwise renaming an argument is a breaking change

[13:45:52.0000] 
I am not proposing renaming the arguments.

[13:46:13.0000] 
i mean

[13:46:19.0000] 
you would then have the problem

[13:46:27.0000] 
of renaming arguments being a breaking change

[13:46:36.0000] 
even if people didn't want others to call their functions that way

[13:46:48.0000] 
so you'd have to do something like swift

[13:46:53.0000] 
its a lot of complexity

[13:47:39.0000] 
i suspect it'd have to be optional in that it's up to the function itself if it can be called that way, and there'd also have to be a reflection method from outside to dynamically know when it's safe to call it that way

[13:48:03.0000] 
also `f(a = 2)` creates a global variable called `a`, or is an error in strict mode, so we'd want to avoid anything that looked like assignment

[13:52:04.0000] 
Yes, that is why I dropped assignment operator.

[13:52:53.0000] 
`:=` looks like assignment too

[13:52:56.0000] 
because it has an equals sign in it

[13:54:47.0000] 
I am not sure I follow the last sentence.  `:=` is intended to be one operator.  Like how ... is not same as the dot operator.

[13:55:18.0000] 
* an operator.  Or well, a way to use the value for a given named parameter.

[14:00:50.0000] 
`:=` was previously proposed to mean "assign with Define"

[14:08:41.0000] 
We could go with =: if that is already taken.


2020-01-19
[16:50:59.0000] 
I’m fuzzy on what advantage this would have over opts-objects, which seem to cover this need pretty elegantly without requiring novel concepts or new reflection utils and without being susceptible to the problems seen in some other languages like devsnek mentioned.

[16:53:30.0000] 
(I’d also consider it a major advantage that opts-objects don’t also allow for specifying the same arg by both name or positional — it’s one or the other)

[18:31:36.0000] 
f(...{first, last}) doesn't look like an assignment 🤔

[18:39:11.0000] 
ljharb: alrighty finished addressing feedback and rebasing on the ecmarkup stuff at last

[18:39:34.0000] 
(I don't usually like to have dependent PRs but I thought it was easiest in this case...)


2020-01-20
[12:19:42.0000] 
do we have a place that we keep track of errata in released editions

[12:22:44.0000] 
devsnek: we have https://tc39.es/ecma262/#sec-intro but that talks about major changes, Annex E but that talks about back-incompat changes, maybe https://tc39.es/ecma262/#sec-corrections-and-clarifications-in-ecmascript-2015-with-possible-compatibility-impact ?

[12:23:07.0000] 
hmm

[12:23:12.0000] 
i'm thinking like

[12:23:15.0000] 
for each edition

[12:23:16.0000] 
the intro and annex e have been audited recently, but i've not ever looked at annex d

[12:23:19.0000] 
a list of known errata

[12:23:31.0000] 
not that i know of

[12:23:42.0000] 
but tbh if someone compiled that, it seems like a reasonable Annex to add

[12:23:56.0000] 
well i dunno if it would be a part of the spec itself

[12:24:13.0000] 
something like this https://www.w3.org/2019/12/wasm-errata

[12:24:19.0000] 
that's the only yearly artifact afaik

[12:25:00.0000] 
i mean the errata shouldn't be editioned

[12:25:02.0000] 
it should be living

[12:25:58.0000] 
¯\_(ツ)_/¯ feels like an annex in the living spec is the way to do that

[12:26:13.0000] 
if its excluded from published editions sure

[12:26:30.0000] 
not sure why we'd want to exclude it

[12:26:46.0000] 
someone looking at the 2020 snapshot still would want to know what errata were in it and not in 2019

[12:27:08.0000] 
right so you keep a living list saying which bugs were found when in which editions

[12:27:20.0000] 
like w3 does

[12:27:35.0000] 
right, the entire spec is living

[12:27:45.0000] 
every word in a yearly snapshot is potentially obsolete already

[12:27:59.0000] 
i'm just saying

[12:28:05.0000] 
the list should not be part of the snapshot

[12:30:21.0000] 
right, i'm not understanding why it shouldn't

[12:30:50.0000] 
its value exists whether you're looking at a snapshot or the actual spec

[12:31:10.0000] 
i don't see any value in an outdated list

[12:31:24.0000] 
it's the exact same value in an outdated spec

[12:31:37.0000] 
if we exclude outdated info, then we just don't ever cut a yearly edition

[12:31:58.0000] 
then maybe we shouldn't put it as part of the spec

[12:32:09.0000] 
lol then there's nowhere for it to go

[12:32:16.0000] 
tc39.es/errata

[12:32:20.0000] 
i really don't understand tho why a snapshot of the errata isn't valuable

[12:32:54.0000] 
because the point of the list is issues found after the fact

[12:33:06.0000] 
right. and every yearly snapshot is "after the fact" of every previous year

[12:33:13.0000] 
if errata in the errata can be in the errata list

[12:33:15.0000] 
so the 2020 spec would contain the errata for 2019

[12:33:16.0000] 
you have a problem

[12:33:24.0000] 
well yeah, it wouldn't be recursive

[12:33:30.0000] 
the errata list would just be updated

[12:33:35.0000] 
plus 2019 errata can be found any time later

[12:33:42.0000] 
in 2023 someone might find a mistake

[12:34:09.0000] 
sure

[12:34:19.0000] 
the 2020 errata list isn't exhaustive, it's just "as of 2020 being cut"

[12:34:33.0000] 
i dunno what the value of that is though

[12:34:42.0000] 
the identical value as "as of right now"

[12:34:46.0000] 
i don't know why i would ever want to read that

[12:35:05.0000] 
seeing how ecma262 worked in 1995 is cool

[12:35:25.0000] 
but seeing an incomplete list of issues is just annoying

[12:35:30.0000] 
so is seeing what kinds of errors are found in different years

[12:35:41.0000] 
yeah that's why on the living page

[12:35:43.0000] 
you put the date out

[12:35:44.0000] 
found*

[12:36:46.0000] 
i think w3 made a good choice of listing them separately from the actual specifications


2020-01-22
[16:34:26.0000] 
i have a comment in es6-shim that mentions how Chrome 38 shipped Array keys/entries/Symbol.iterator, but not values. Chrome shipped it in later versions. I'm now checking on Chrome 38, however, and it seems that Array.prototype.values is there. Is it possible that Chrome wrapped it in a live-updating feature flag as far back as 2014, and that *all* versions of Chrome that have keys/entries/Symbol.iterator now also have values?

[16:34:45.0000] 
cc gsathya mathiasbynens for the v8 question ^

[16:41:13.0000] 
actually now that i'm checking, chrome 39 and 40 lack values but have Symbol.iterator, so maybe it's just that my comment is wrong

[17:03:43.0000] 
ljharb: it was removed for compat reasons

[17:03:47.0000] 
but later added back

[17:08:40.0000] 
Curious, what compat reason?

[17:11:08.0000] 
devsnek: i remember that, but that's why i'm confused that it's in 38 when my es6-shim comment suggests i tested 38 and it wasn't there

[17:11:29.0000] 
devsnek: so either my comment was wrong (and it was 39), or browserstack's chrome 38 isn't the latest chrome 38, i guess

[17:11:56.0000] 
jackworks: some enterprise installations of outlook, iirc, that were doing `values in foo` to determine if it was a custom object or an array

[22:04:44.0000] 
jackworks: it broke the web https://bugs.chromium.org/p/v8/issues/detail?id=4247


2020-01-23
[17:17:05.0000] 
so I'm just gonna ask this here for good measure before creating an issue, but Yusuke pointed out that the spec is perhaps more conservative than necessary in saying which ISO 8601 time zone designators are allowed in a date time string

[17:17:10.0000] 
namely

[17:17:32.0000] 
(as of the latest JSC revision)

[17:18:05.0000] 
in what way?

[17:18:15.0000] 
JSC / V8 / SM / XS / Ch are _all_ able to handle Date.parse('1970-01-01T00:00:00.000+2300')

[17:18:19.0000] 
i.e. without the colon

[17:18:39.0000] 
and JSC / XS / Ch are even able to handle Date.parse('1970-01-01T00:00:00.000+23')

[17:18:48.0000] 
i.e. just hh without mm

[17:19:36.0000] 
those are implementation-dependent extension that I do not believe should be mandated by spec

[17:20:33.0000] 
the latter example seems trickier since we'd be requiring something that V8 and SM (and even JSC before today) haven't been doing but

[17:21:05.0000] 
if all implementations are allowing the dropped colon, I think Yusuke has a point that it would be reasonable to specify it, since it is a part of ISO 8601?

[17:21:50.0000] 
it is only a part of ISO 8601 _basic format_, which drops all punctuation other than the + or - preceding UTC offset

[17:21:56.0000] 
gibson042: yeah, I do understand that anything beyond what's specified is an implementation-dependent extension but

[17:22:05.0000] 
hmm

[17:22:12.0000] 
but as noted in RFC 3339, "ISO 8601 is not clear if mixtures of basic and extended format are permissible"

[17:22:30.0000] 
ohh that's very interesting

[17:22:54.0000] 
YYYYMMDDThhmmss±hhmm is explicitly allowed (basic format), and YYYY-MM-DDThh:mm:ss±hh:mm is explicitly allowed (extended format)

[17:23:00.0000] 
but mixtures are not mentioned

[17:23:23.0000] 
I see

[17:24:02.0000] 
and the ECMAScript format is based on (and only requires support for) a subset of extended format

[17:24:34.0000] 
(looking at that RFC, it's also interesting that their `ISO 8601 is not clear on whether an hour of 24 is permissible only if minutes and seconds are 0.  This assumes that an hour of 24 is permissible in any context.` is what JSC / XS / Ch do but not V8 / SM)

[17:25:40.0000] 
gibson042: would you vote then that it's better to stick to just specifying ISO 8601 extended format versus "what's intersectionally allowed by all major implementations"?

[17:26:08.0000] 
yeah, that's a problem in its own right because ISO 8601 only intended hh=24 for the end of a calendar day *within a time interval*, not for isolated date and time of day values

[17:26:24.0000] 
yes

[17:26:44.0000] 
yeah. I don't think I want to touch the hh=24 thing either  😓

[17:26:56.0000] 
okay, I can convey that back then

[17:27:17.0000] 
others may disagree, of course

[17:27:19.0000] 
context was https://bugs.webkit.org/show_bug.cgi?id=160287 if you're curious

[17:30:38.0000] 
"The end of day representation, where [hh] has a value of [24], shall not be used for a single time point." /whoops

[17:31:25.0000] 
but yeah, certainly not intended for use with nonzero minutes/seconds/subseconds

[17:33:05.0000] 
right

[17:33:13.0000] 
pretty awkward 😓


2020-01-26
[20:05:11.0000] 
🤔 does there any proposal like `import.self` to resolve this problem (`process.mainModule === module` esm equivalent)? https://github.com/nodejs/node/issues/15760

[20:07:00.0000] 
jackworks: the recommendation for node is to use a separate file for "main" and "bin"; it's considered an antipattern to conflate them

[20:07:26.0000] 
jackworks: node could handle it without any proposal by adding `import.meta.something`, but the modules group decided not to support the antipattern.

[20:08:22.0000] 
ok... so maybe there is no more use case need to reference the module itself I guess

[20:10:25.0000] 
jackworks: i mean, you can self-reference the package in node 13.7+ by using the package name

[20:10:46.0000] 
jackworks: and theoretically you should be able to `import * as self from '.'` (altho i don't think that works right now)

[20:11:32.0000] 
won't `import * as self from '.'` cause side effect?

[20:12:18.0000] 
how?

[20:12:25.0000] 
it's a circular dep, but it wouldn't repeat any side effects

[20:14:15.0000] 
you're right

[20:46:42.0000] 
self-import (including namespace) appears to work in node (13.7.0)

[20:47:46.0000] 
(though maybe you mean import relying on package.json for resolution, I’ve only tried with './specific-module-name.mjs')

[20:49:27.0000] 
if you do need to test if the current module is the entrypoint, process.argv might give you the means, though I’d be nervous about relying on it

[20:58:09.0000] 
bathos: self package import does. Self module import does too, you’re saying? (without repeating the file name)

[21:10:21.0000] 
I’d tested foo.mjs importing foo.mjs. I didn’t test foo.mjs importing a package with "main": "foo.mjs". I’ll check it out now tho

[21:12:28.0000] 
I get a "Cannot find module" error when I try ".", yeah.

[21:14:04.0000] 
that’s what i think node needs to add support for. It works in browsers i think

[21:18:06.0000] 
browsers with import maps you mean?

[21:19:23.0000] 
(I haven’t tried import maps yet, but afaik that’s the closest analog, since otherwise it’s just URLs-that-cannot-be-pathname-relative-unless-they-start-with-dot-slash-or-dot-dot-slash-or-slash.)

[21:22:57.0000] 
(i.e. in a browser self-import works fine, but "." alone would be rejected at step 2 here html.spec.whatwg.org/multipage/webappapis.html#resolve-a-module-specifier)

[21:24:21.0000] 
no, i mean no import maps

[21:24:43.0000] 
but fair, that seems like a gap in browser esm too

[21:24:56.0000] 
`.` is the current URL in every other browser relative url context

[21:28:27.0000] 
Yeah, I’m not sure what the point of eliminating "." there is (perhaps it was an oversight). It doesn’t seem necessary for the purpose of reserving "bare names".

[21:34:15.0000] 
right


2020-01-30
[12:58:48.0000] 
did a quick google and didn't find anything useful, what is the historical reason for UCS-2/UTF-16 over UTF-8 in the spec? don't have an opinion, it just came up today

[13:10:07.0000] 
michaelficarra mnay know (re "what is the historical reason for UCS-2/UTF-16 over UTF-8 in the spec?")

[13:11:57.0000] 
(I imagine the answer is simply: impl circa 1995 used UCS-2 and was never changed)

[13:22:54.0000] 
it uses utf16 because java uses utf16

[14:27:02.0000] 
can anybody think of a justification for why built-in objects are sometimes written in unstylized text? e.g. "Date constructor" appears 5 times and "`Date` constructor" appears 3 times (ignoring section title appearances)

[14:28:25.0000] 
I can go through and deal with 'em, but sometimes somebody like jmdyck is able to find a good reason for the status quo that I've overlooked, so I'm asking here first :D

[14:28:59.0000] 
they should probably link to the relevant section

[14:32:21.0000] 
perhaps but that'd be a wholly separate task

[14:33:41.0000] 
I can't think of a justification.

[14:36:21.0000] 
what's the context of each?

[14:36:37.0000] 
i'd probably backtick `Date` when talking about code but not when referring to it conceptually

[14:44:40.0000] 
ljharb: I mean that was the best sort of thing I could conceive of

[14:46:12.0000] 
I initially noticed this because 402 has like

[14:46:35.0000] 
"the options object provided to the Intl.DateTimeFormat constructor" (which is just totally unstyled)

[14:46:52.0000] 
and that's sort of based on 262's precedent but

[14:47:32.0000] 
feels pretty weird to me to see a dot access in unstylized text

[15:30:00.0000] 
it's kind of interesting though, because like

[15:30:20.0000] 
"Date object" is always just plain

[15:31:13.0000] 
is a date object a date instance?

[15:31:27.0000] 
I think same for {object, type, value}

[15:31:48.0000] 
there's always one more editorial task :(

[15:31:56.0000] 
instance too yeah

[15:32:06.0000] 
"Date instance" I mean

[15:32:22.0000] 
(obviously Date isn't special here, just an easy example)

[15:34:39.0000] 
so then this makes me wonder instead if the cases of "`Date` constructor" are necessarily legitimate

[15:34:48.0000] 
because that would be the smallest diff by far

[15:55:06.0000] 
what are the context of those?

[15:58:08.0000] 
seemingly random but consistent for various built-ins

[15:58:23.0000] 
it would be quicker to have you glance than to try to describe it


2020-01-31
[16:04:26.0000] 
with "Array constructor" it's even more pronounced

[16:06:11.0000] 
basically just Table 8: Well-Known Intrinsic Objects and this one sentence that occurs for all built-ins that has like "`Array` behaviour must include a `super` call to the `Array` constructor"

[16:07:00.0000] 
wherein "`Array` behaviour" definitely feels wrong and I think the backticks for `Array` constructor should be abandoned there too since it's just a one-off case

[13:17:53.0000] 
augh this whole thing is arranged in a way that makes me not even want to touch it though

[13:19:17.0000] 
like you could say like okay " {object, type, value, instance, prototype}" is always written without backticks and " constructor" is *usually* written without backticks so we should make that usually into an always

[13:19:24.0000] 
definitely doable, but

[13:19:54.0000] 
something like

[13:19:54.0000] 
```

[13:19:54.0000] 
The GeneratorFunction constructor:

[13:19:54.0000] 
- is a standard built-in function object that inherits from the `Function` constructor.

[13:19:54.0000] 
```

[13:19:54.0000] 
is particular annoying

[13:20:45.0000] 
it's like, yeah, on its own, "inherits from the `Function` constructor" looks like exactly what I would've been inclined to write

[13:21:48.0000] 
but like it's not even consistent within the scope of that bullet list as a whole

[13:22:17.0000] 
sigh

[13:31:02.0000] 
I mean I guess in cases where it says like "use" or "call" or "provide arguments to" then we're clearly talking about code

[13:31:26.0000] 
but inheritance seems like it could be conceptual. maybe I'll try to distinguish that accordingly.

[13:33:00.0000] 
yeah so then maybe the Well-Known Intrinsic Objects table should change but then like

[13:34:02.0000] 
in the earlier example of "`Array` behaviour must include a `super` call to the `Array` constructor" maybe "Array behaviour" could go without but "call to the `Array` constructor" could be said to need 'em

[13:34:23.0000] 
(I dunno how I get so nerd-sniped by stylistic matters like this...)

[13:38:12.0000] 
on the other hand,

[13:38:12.0000] 
```

[13:38:12.0000] 
20.4.2.2 Date ( value )

[13:38:12.0000] 
This description applies only if the Date constructor is called with exactly one argument.

[13:38:12.0000] 
```

[13:38:13.0000] 
still does feature the verb "call" and is written without backticks :neutral_face:

[14:58:26.0000] 
this should be an improvement at least 😕 https://github.com/tc39/ecma262/pull/1860

[15:36:17.0000] 
rkirsling: thank you for all your editorial PRs

[15:36:36.0000] 
shu: glad it's not annoying 😅