2025-07-02
[03:20:03.0894] <Michael Ficarra>
FYI a student will be opening some PRs and issues related to https://github.com/tontonialberto/ecma262-spec-inconsistencies

[05:24:44.0464] <jmdyck>
They don't seem to be aware that there are semantically different uses for [[Foo]] notation.

[05:39:21.0066] <jmdyck>
or that objects don't have 'fields'.

[05:52:05.0781] <Michael Ficarra>
yes I spoke to him about that already

[05:52:16.0440] <Michael Ficarra>
he won't be opening a PR for that

[05:53:15.0430] <jmdyck>
the if/else stuff is valid, but he's missing some variations.

[05:58:22.0548] <Michael Ficarra>
those are the only ones he's interested in

[05:58:51.0579] <Michael Ficarra>
I also got a question today about what the repeat-until step's semantics should be https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-bigintbitwiseop

[05:59:16.0575] <Michael Ficarra>
does it imply that the steps should be executed at least once?

[05:59:47.0305] <Michael Ficarra>
like a do-while with a negated condition

[06:00:46.0084] <Michael Ficarra>
by this, I mean ones that have the consequent/alternative on the same line as the if/else/else-if

[06:01:38.0845] <jmdyck>
CreateIntrinsics step 2 is indeed problematic, but I don't think it can be broken into a series of more-parseable steps.

[06:02:15.0118] <Michael Ficarra>
yeah I don't think it needs to be broken down, but its phrasing can probably be modernised

[06:03:54.0456] <Michael Ficarra>
and probably it would be better to explicitly loop over table rows

[06:04:12.0096] <jmdyck>
My inclination is that step 2 should become its own section, where you can at least let things breathe in separate paragraphs, lists.

[06:05:34.0850] <Michael Ficarra>
once he opens the issue about it, we can dump our ideas in there and I'll label it as "editor call"

[06:05:55.0123] <Michael Ficarra>
I think he was hoping that our changes to that step could get esmeta to automatically understand it, but I don't see that happening

[06:06:49.0434] <jmdyck>
The thing about explicitly looping over table rows is you can't make a single pass over the table and completely create an object at each iteration, because there are cycles in the references.

[06:07:14.0172] <Michael Ficarra>
ah, right

[06:07:39.0870] <Michael Ficarra>
you'd have to topo-sort the table, which is... not great if you want to peruse the table manually

[06:28:15.0123] <jmdyck>
You could conceivably do 2 passes, one pass to partially create the objects (without any references), then another pass to add the references (properties + [[Prototype]]).  Then you wouldn't need a topo-sort. However, the spec says that built-in functions are created with CreateBuiltinFunction, which takes a _prototype_ arg. So if you want to respect that, you have to do a topo-sort on [[Prototype]].

[06:29:13.0041] <jmdyck>
The table wouldn't have to be topo-sorted in the source, CreateIntrinsics can just say to sort it, which is basically what it does now.

[06:29:55.0846] <jmdyck>
"The creation of the intrinsics and their properties must be ordered to avoid any dependencies upon objects that have not yet been created."

[06:30:25.0254] <jmdyck>
However, the implications of that sentence aren't obvious.

[06:38:53.0485] <jmdyck>
But even if that part of the algorithm were made more explicit, esmeta would probably still need one-off stuff to parse it.

[06:43:52.0104] <Michael Ficarra>
this isn't a KAIST student btw

[06:45:47.0562] <jmdyck>
And that'd still leave the ~half of step 2 that talks about how you invoke CreateBuiltinFunction. I suppose you could do something like:
If the intrinsic to be created is a built-in function, then
- Let _steps_ be the definition of that function provided by this specification.
- Let _length_ be the initial value of the function's "length" property.
- [etc]
- Let _intrinsic_ be CreateBuiltinFunction(_steps_, _length_, ...).
- Set ... to _intrinsic_.

[06:46:10.0935] <jmdyck>
That would at least be more readable to humans.

[06:48:02.0308] <Michael Ficarra>
yeah that's exactly what I was thinking

[06:52:11.0199] <jmdyck>
Hm. So now I'm now more optimistic about breaking step 2 into steps, but (a) they're not necessarily more parseable, and (b) it's not trivial.

[06:52:21.0875] <jmdyck>
* Hm. So now I'm now more optimistic about breaking step 2 into substeps, but (a) they're not necessarily more parseable, and (b) it's not trivial.

[10:56:19.0775] <shu>
so for the week of july 7, we need a new time on either monday or friday

[10:56:26.0256] <shu>
my tue-thu literally have no free time

[10:57:03.0777] <shu>
Michael Ficarra: bakkot slots that work for you?

[10:57:46.0982] <bakkot>
after noon either day is currently free

[10:57:51.0491] <bakkot>
* after noon either day is currently free for me

[11:04:36.0577] <jmdyck>
Michael Ficarra: will there be videos of PLSS talks?

[14:34:11.0035] <bakkot>
jmdyck: https://www.youtube.com/live/r4imci31ntw?t=12168s

[14:34:14.0805] <bakkot>
unless you meant something else

[14:39:37.0646] <jmdyck>
That's PLDI, I was asking about PLSS this Friday. Some overlap in talks though.

[14:39:59.0648] <bakkot>
oh, sorry, I stopped reading after the first two letters apparently

[14:40:06.0239] <jmdyck>
heh

[14:43:28.0684] <jmdyck>
or I guess more specifically it was RPLS @ PLDI (vs PLSS @ ECOOP)

[14:48:02.0321] <Michael Ficarra>
I was asked for permission to record, so I guess that implies they will be recorded

[14:48:29.0315] <Michael Ficarra>
though my talk and Jihyeok's talk should be the same as RPLS

[14:48:50.0456] <Michael Ficarra>
or at least very very close

[14:49:26.0045] <jmdyck>
cool, thx

[14:52:39.0732] <Michael Ficarra>
you're gonna have to do before noon if we want to include Linus from now on (or move East)

[14:52:59.0023] <Michael Ficarra>
how about 11:30A Mountain?

[14:54:10.0886] <bakkot>
I was assuming we were just talking about the week of July 7

[14:54:24.0705] <bakkot>
not a permanent slot

[15:34:09.0139] <shu>
think about a permanent slot too

[15:34:26.0002] <shu>
my tue-thu are completely full for the foreseeable future


2025-07-04
[21:20:50.0150] <shu>
Michael Ficarra: i'd prefer fri actually

[21:21:13.0068] <shu>
1130 MST fri?

[22:32:38.0715] <Michael Ficarra>
I try to keep my Fridays meeting-free, but for next week that's fine until we figure out a permanent schedule

[03:08:00.0618] <Michael Ficarra>
what do you think about sections defining built-ins having a toggle to show example invocations and their results?

[03:08:13.0633] <Michael Ficarra>
just leave it to MDN?


2025-07-07
[08:58:03.0161] <shu>
please PM me the emails you'd like the invite sent to, i lost them with the job switch

[09:11:49.0506] <ljharb>
if it's for the tc39 calendar, i can do it if you like, just lmk what timeslot

[09:46:00.0308] <Michael Ficarra>
@ljharb:matrix.org 10:30A Pacific this Friday only at https://appleinc.webex.com/appleinc/j.php?MTID=m85786fc149f3b3d30b54a26c1990724d

[10:01:11.0212] <ljharb>
k, moved wednesday's to friday

[10:01:14.0228] <ljharb>
lmk if you need anything else


2025-07-10
[13:00:22.0021] <Michael Ficarra>
why does `npm ci` keep hanging forever?

[13:00:51.0026] <Michael Ficarra>
this seems to be most jobs on most commits lately: https://github.com/tc39/ecma262/actions/runs/16186676414/job/45693572328?pr=3642

[13:01:22.0158] <Michael Ficarra>
this isn't new but it used to happen very rarely

[15:06:48.0548] <ljharb>
good question. the one i'm waiting to merge has been having the same problem


2025-07-11
[15:42:31.0421] <Michael Ficarra>
what is going on?


2025-07-12
[21:21:12.0186] <ljharb>
srsly, fd if i know.

[21:21:20.0103] <ljharb>
there's no error output, it's just hanging

[07:30:25.0952] <jmdyck>
MF was maybe asking about the multiple close+reopen.


2025-07-14
[22:15:30.0275] <ljharb>
the point of doing that is just to restart all the CI jobs. the reason for needing to do it is the hanging

[07:22:10.0857] <Michael Ficarra>
This doesn't seem to be a good long-term solution. Is the hanging an npm thing or an us thing? Is anyone else experiencing this? We're just running `npm ci`, we're not doing anything unusual, right?

[08:20:20.0761] <ljharb>
it’s not even a short term solution, because it’s not actually fixing anything. I’ll look into it this week

[13:23:43.0376] <ljharb>
ok, i think i figured it out. basically the fix was to update the sha of my github action workflows - since mine are the only ones pinned to a sha and ecma262 is the only consumer of mine that is pinned, i totally forgot about the need to update them. please stamp https://github.com/tc39/ecma262/pull/3646 and add the label, and i'll get all the pending PRs landed.

[13:23:59.0689] <ljharb>
* ok, i think i figured it out. basically the fix was to update the sha of my github action workflows - since mine are the only ones pinned to a sha and ecma262 is the only consumer of mine that has them pinned, i totally forgot about the need to update them. please stamp https://github.com/tc39/ecma262/pull/3646 and add the label, and i'll get all the pending PRs landed.

[14:34:44.0565] <ljharb>
(it's ready to land)

[15:04:10.0465] <Michael Ficarra>
uuggghhh why do you check in your `node_modules`?

[15:04:14.0451] <Michael Ficarra>
this diff is enormous https://github.com/ljharb/actions/compare/dfd9796898850cf07630d1bd4053a7c9a379e90f...7f214d8efdbdcefc96ad9689663ef387a195deec

[15:10:27.0594] <ljharb>
because actions have to.

[15:10:50.0746] <ljharb>
* because all actions have to.

[15:11:19.0990] <ljharb>
* because all actions have to. i'd much rather not, checking in node_modules is horrendous

[15:28:51.0304] <ljharb>
merge label, or should i just land it anyways?

[15:30:58.0471] <Michael Ficarra>
added the label


2025-07-15
[13:58:46.0591] <Michael Ficarra>
@ljharb:matrix.org can you cancel the Wednesday editor call calendar event for the 16th, 23rd, and 30th?

[15:33:58.0788] <ljharb>
sure


2025-07-16
[10:44:19.0705] <Michael Ficarra>
huh https://ecma262.com/

[10:45:25.0001] <bakkot>
that's been up for a while I think?

[10:46:10.0332] <Michael Ficarra>
I hadn't seen it

[10:46:13.0770] <Michael Ficarra>
is it... maintained?

[10:47:01.0305] <Michael Ficarra>
it appears to be

[10:47:17.0709] <Michael Ficarra>
the ToC is so much more compact 😍

[12:54:14.0453] <jmdyck>
re https://github.com/tc39/ecma262/pull/2962 should I 'fold in' the fixup commits, or leave them as is (modulo rebasing)? Not that I'm expecting anyone to look at it soon, just that I currently have it paged in to resolve merge conflicts.

[13:35:34.0548] <jmdyck>
Getting CI failures in esmeta step because scala can't download akka?

[15:12:47.0671] <Michael Ficarra>
I'd leave them split out so anyone who has already done a review can just review the fixups

[16:19:45.0414] <jmdyck>
ok, thanks


2025-07-17
[14:41:06.0630] <Michael Ficarra>
`JSON.parse` does an `IsCallable` check on `reviver` before passing it to `InternalizeJSONProperty`, but `InternalizeJSONProperty` types that argument as "a function object"

[14:41:18.0976] <Michael Ficarra>
esmeta rightfully complains because those types don't match up

[14:41:24.0928] <Michael Ficarra>
what should we do?

[14:44:37.0861] <Michael Ficarra>
🤔 though it's strange that it wouldn't complain about the same thing with `Function.prototype.bind` and `BoundFunctionCreate`...

[14:45:39.0893] <Michael Ficarra>
it's possible that it's already skipping one of those for some other reason, I'll take a look

[14:46:27.0236] <Michael Ficarra>
btw this would be easier if someone stamped https://github.com/tc39/ecma262/pull/3651 and we merged it

[15:07:48.0996] <bakkot>
rubberstamped, I am just going to trust that this does what it looks like and not try to actually check anything about github actions

[15:08:13.0828] <bakkot>
how does `IsCallable` not imply "a function object"?

[15:08:36.0279] <bakkot>
"A function object is an object that supports the [[Call]] internal method"

[15:09:11.0855] <bakkot>
`IsCallable` is true iff the argument is an object and has a [[Call]] internal method

[15:10:05.0508] <bakkot>
I guess we could tweak the prose of IsCallable to say "determines if _argument_ is a function object", which would be an improvement over the current word salad:

> a callable function with a [[Call]] internal method

but I don't think that would affect esmeta by itself

[15:13:58.0097] <Michael Ficarra>
esmeta says it could also be a Proxy object that implements [[Call]]

[15:14:54.0809] <jmdyck>
and that's a function object

[15:17:34.0969] <Michael Ficarra>
ah, fair

[15:19:42.0412] <Michael Ficarra>
this is why we should rename that to callable object, it's so unintuitive

[15:20:21.0735] <jmdyck>
rename "function object" to "callable object" ?

[15:21:45.0937] <ljharb>
but a callable object is a function

[15:21:50.0167] <ljharb>
a proxy for a function is also a function

[15:22:39.0488] <jmdyck>
See also https://github.com/tc39/ecma262/pull/2889


2025-07-21
[08:41:02.0906] <Michael Ficarra>
I think today's editor call might not be on the TC39 calendar

[09:24:28.0166] <ljharb>
it's not

[09:24:32.0695] <ljharb>
is it every monday moving forward?

[09:25:32.0034] <ljharb>
i have friday july 11th, and then nothing until wednesdays starting august 6th

[09:31:55.0444] <Michael Ficarra>
umm I can't remember if this was the new timeslot going forward or not

[09:32:02.0497] <Michael Ficarra>
I *think* so? We should confirm with Shu

[09:32:10.0437] <Michael Ficarra>
either way, there's no meeting next week due to plenary

[09:32:30.0789] <Michael Ficarra>
so we can just add this as a one-off and set the recurring one to start the week after plenary

[09:32:53.0490] <Michael Ficarra>
today's meeting is 13:00 Mountain time btw

[09:34:18.0172] <Michael Ficarra>
btw I'd like to talk about some new esmeta features at today's editor call

[09:36:07.0518] <jmdyck>
so ~2.5 hrs from now?

[09:42:10.0068] <Michael Ficarra>
yeah

[13:58:20.0735] <Michael Ficarra>
here's the esmeta logs I was referring to in today's editor call: https://gist.github.com/michaelficarra/8ed4c5d1243dc1465f14e90623e1c8c9

[13:59:03.0630] <Michael Ficarra>
some of them are low-hanging fruit for the esmeta parser, some are low-hanging fruit for us to clean up

[14:05:34.0241] <jmdyck>
(I'll just point out that ecmaspeak can parse all of these.)

[14:56:17.0763] <jmdyck>
From what little I know about esmeta, it's harder for them because they need to declare a data structure for each different form that they parse.

[14:57:48.0602] <jmdyck>
Whereas ecmaspeak just has a grammar, so everything gets parsed into the same generic parse-tree structure.

[14:58:42.0905] <jmdyck>
* Whereas ecmaspeak just has a grammar, and everything gets parsed into the same generic parse-tree structure.

[14:58:59.0734] <Michael Ficarra>
no I don't think that's true from how Jihyeok described it to me

[15:05:26.0571] <Michael Ficarra>
man, every time I look through the code, I am completely lost though

[15:05:39.0084] <jmdyck>
E.g., the structures declared in https://github.com/es-meta/esmeta/blob/6038a20b263d51410e1b8112157af9b1f413349e/src/main/scala/esmeta/lang/Step.scala#L16

[15:05:49.0240] <jmdyck>
* E.g., the structures declared in https://github.com/es-meta/esmeta/blob/6038a20b263d51410e1b8112157af9b1f413349e/src/main/scala/esmeta/lang/Step.scala

[15:06:39.0871] <Michael Ficarra>
ah, yes, but that structure is associated with many possible concrete forms

[15:06:42.0087] <Michael Ficarra>
see https://github.com/es-meta/esmeta/blob/main/src/main/scala/esmeta/lang/util/Parser.scala#L108-L113

[15:07:12.0717] <Michael Ficarra>
* see https://github.com/es-meta/esmeta/blob/main/src/main/scala/esmeta/lang/util/Parser.scala#L108-L115

[15:07:52.0982] <Michael Ficarra>
anywhere there's a `|` or an `opt` means many concrete forms can parse to the same thing

[15:08:52.0665] <jmdyck>
sure, but presumably the "yet-steps.txt" are concrete forms that no structure corresponds to. So in order to handle them, they'll need to either declare a new structure, or generalize an existing one. 

[15:09:44.0333] <Michael Ficarra>
so for example those "for each code point ..." loops in `yet-steps.txt` can be supported with just a parser change to allow more than just `opt("element")` here: https://github.com/es-meta/esmeta/blob/main/src/main/scala/esmeta/lang/util/Parser.scala#L131-L137

[15:11:15.0016] <Michael Ficarra>
and I think they actually had just as little visibility into this as we did until recently


2025-07-25
[11:49:17.0600] <Michael Ficarra>
it's strange that we capitalise nearly all occurrences of the ES language types in the spec except for Object, which is usually lowercased


2025-07-28
[20:54:03.0540] <shu>
the current timeslot is the only one that works for me at the moment that's not on a friday

[20:54:12.0162] <shu>
i'd still prefer a friday slot, actually

[21:34:08.0258] <Michael Ficarra>
btw F5 has a holiday on Aug 1 and Aug 4