TC39 Delegates
2024-12-03
plaintext logs
prev next
source on github
16:53
<littledan>
Should we do this for ShadowRealms though?
17:12
<dminor>
https://github.com/mozilla/standards-positions/issues/997
17:22
<shu>
i thought porffor was an engine, it's a runtime as well?
17:22
<ljharb>
what's the difference between those two, to you?
17:23
<shu>
the difference between Node and V8
17:23
<ljharb>
d8 is a runtime tho, no?
17:23
<shu>
hahahahaha
17:23
<shu>
no
17:24
<snek>
you could call d8 a test262 runtime
17:24
<littledan>
I think porffor is working on developing into a runtime, yes
17:24
<littledan>
canadahonk: ^
17:24
<ljharb>
so what's the concrete rubric that node passes but d8 doesn't?
17:24
<ljharb>
(genuinely asking, tbc)
17:24
<littledan>
the intentions of the maintainers?
17:24
<shu>
at the very least, a desire and goal to actually support workloads beyond "the bare minimum needed to run tests"
17:24
<ljharb>
i mean if that's all it is then that's simple enough
17:25
<littledan>
in particular, TC55 is for server-type environments, which Node is intended to be, and d8 isn't
17:25
<shu>
like there is little rhyme or reason for "features" that exist in d8, how they work, beyond "whatever's bare minimum needed to run our tests and the test262 harness"
17:25
<ljharb>
porffor tho makes standalone executables, so is that not a runtime?
17:25
<shu>
no, IMO it needs a set of APIs and intention as dan says
17:26
<shu>
otherwise every engine is also a runtime
17:26
<shu>
and obviously we're not
17:26
<Chris de Almeida>
porffor famously does not ship a runtime
17:26
<snek>
unless you reference globalThis
17:26
<littledan>
yeah porffor isn't ready yet; this is about goals
17:26
<Rob Palmer>
Technically Porffor refers to itself as a compiler, rather than an engine. And the resulting programs are more useful than base ecma262 allows, e.g. io. https://porffor.dev/
17:26
<canadahonk>
oh no I regret not joining the call now
17:27
<littledan>
please come to the GA and vote in favor of chartering TC55, everyone!
17:27
<nicolo-ribaudo>
The definition of "runtime" is "whatever people consider to be a runtime"
17:27
<Rob Palmer>
Don't worry canadahonk , it was barely mentioned in plenary.
17:27
<canadahonk>
currently I would call it a compiler and engine
17:27
<canadahonk>
it is as much a runtime as d8 currently
17:27
<Rob Palmer>
(the conversation here in the matrix is the main part)
17:28
<ljharb>
ok thanks, that clarifies the meanings for me
17:28
<ljharb>
(and "runtime" clearly has a very hand-wavy one)
17:29
<canadahonk>
(long-term yeah I'd like it to be more like node in terms of api/io capability but that is far away for now. there a few apis providing i/o but they are largely proof-of-concept rather than nice for now)
17:31
<canadahonk>
on this point yeah, it will not include anything engine or runtime unless you use it. eg, if you have no usage of Map, in the binary there will be 0 checks for if the type as you know it wasn't used at compile-time
17:31
<Michael Ficarra>
@canadahonk you gonna just implement the wasi APIs?
17:32
<canadahonk>
I'd like to have node(/deno/etc)-like wrappers to make them nicer ideally (also to provide stability with my own API since WASI isn't)
17:32
<littledan>
It will be great to have people working on the correspondence between these things!
17:34
<Michael Ficarra>
personally, I would rather the engine just provide the wasi primitives and then I can pull in a library that adapts them to the high-level node/deno/whatever APIs
17:34
<canadahonk>
fair enough that makes sense to me too, we'll see :)
17:36
<canadahonk>
also fun fact, even worst case using globalThis, so including 100% of engine, the output Wasm is still only <500kb and native <300kb ;)
17:39
<bakkot>
that reminds me I need to pester the wasi people about https://github.com/WebAssembly/wasi-clocks/pull/71 again
17:39
<bakkot>
wasi v2 seems promising but there's still a bunch of warts and it doesn't seem to be moving as fast as I'd hoped
17:49
<Rob Palmer>
I did not realize that return-override stamping objects with private fields degrades their performance.
17:50
<littledan>
Note that the current semantics of private fields was heavily based on Mark's strongly stated goal of private fields being consistently analogous to WeakMaps in semantics.
17:53
<bakkot>
all of these things mark is proposing are things where, it would be nice if the language worked like this, but I am not convinced adding a new and less convenient kind of object with the new semantics is worth doing
17:59
<keith_miller>
Did anyone else's audio fall out?
18:00
<ljharb>
i mean i'd definitely make every object i ever produce non-trapping, because i don't want people to use proxy :-p
18:16
<shu>
bakkot: what are your thoughts on changing non-extensible to include no-private-field-stamping? is that an extra bit of complexity in your view?
18:17
<ljharb>
that would mean sealed and frozen also have that trait, which seems a lot more likely to cause issues
18:17
<shu>
that's correct
18:18
<shu>
right, it's all contingent on being web compat
18:18
<shu>
i don't know of people who are actually doing that
18:18
<ljharb>
private field stamping?
18:18
<shu>
on non-extensibles?
18:18
<ljharb>
oh true, that's a subset of a subset if anything
18:18
<shu>
right
18:18
<ljharb>
but like, if that's low enough that it's web compat, what about return override from class constructors itself?
18:19
<shu>
i'm open to that but i think that does break stuff
18:19
<shu>
with people subclassing html elements or some crap
18:19
<ljharb>
gotcha
18:20
<ljharb>
yeah custom elements seems to need a lot of really weird userland code :-/
18:21
<Ashley Claymore>
My understand is that it's another shape change (in v8 at least) as it's adding a hidden symbol prop. I had assumed it is the same perf hit as adding a public symbol. Maybe that's not the case
18:22
<shu>
yeah i don't think it's any worse than adding any other property
18:23
<bakkot>
bakkot: what are your thoughts on changing non-extensible to include no-private-field-stamping? is that an extra bit of complexity in your view?
I think the whole private-field-stamping thing is something we should simply not tell developers about, so changing how it works does not particularly add complexity
18:23
<bakkot>
so I'm fine with that
18:24
<Ashley Claymore>
I have been wondering if we could have a way to disable proxy hooks, and if that would allow proxies to get a stable shape for ICs.
like
const [proxy, disableTraps] = Proxy.temporary(target, handler);
...
disableTraps();
18:24
<Mathieu Hofman>
I am really worried that people out there, possibly in libraries, did build WeakMap equivalent widgets that use the return override private field stamping trick, and that it would break if we unilaterally prevented return overrides proxy stamping. It's possible that non extensible objects are currently rare enough that they wouldn't break any deployed code.
18:25
<bakkot>
I have been wondering if we could have a way to disable proxy hooks, and if that would allow proxies to get a stable shape for ICs.
like
const [proxy, disableTraps] = Proxy.temporary(target, handler);
...
disableTraps();
I would prefer we just tell people to stop using proxies ever, instead of adding new methods which try to make them a little bit more performant
18:27
<Jack Works>
I have been wondering if we could have a way to disable proxy hooks, and if that would allow proxies to get a stable shape for ICs.
like
const [proxy, disableTraps] = Proxy.temporary(target, handler);
...
disableTraps();

you can remove proxy traps after the creation.

const trap = { ... }
const proxy = new Proxy(obj, trap)
// after some time
delete trap.get
18:27
<ljharb>
yeah that live binding behavior is bonkers to me
18:27
<ljharb>
i wonder if it'd be web compatible to eagerly cache the traps at proxy creation time
18:28
<Mathieu Hofman>
Proxies are an integral part of being able to construct transparent membranes.
18:29
<ljharb>
sure but that's a thing that likely only double digits of humans on the planet ever need to think about (not that we'd remove proxies, just tell the majority not to use them)
18:29
<Ashley Claymore>
Yeah. But engines wouldn't know that the trap isn't going to be added back. Even if it has prevent extensions the handler itself could be a proxy with a get trap 🙁
18:29
<bakkot>
Proxies are an integral part of being able to construct transparent membranes.
I am aware of that and nevertheless strongly stand by my position.
18:30
<Mathieu Hofman>
Guilty of making the handler a proxy. However the engine does know if the handler is a proxy and could opt out of optimizations in that case
18:30
<Jack Works>
sure but that's a thing that likely only double digits of humans on the planet ever need to think about
I use proxy to trap [[Get]] to provide object that every property is defined and functional based on their name
18:31
<Ashley Claymore>
yeah. Maybe the spec already allows engines to optimize for the case I'm interested in. But that doesn't mean it's worth implementing, and even having a dedicated API for it doesn't mean that it has to be implemented in a way that adds a performance win 
18:31
<ljharb>
i'd be curious to see it, but i still don't think there's even 100 people on the planet that need to be using proxy directly
18:31
<Jack Works>
I use proxy to trap [[Get]] to provide object that every property is defined and functional based on their name
in a library called async-call-rpc to provide good DX
18:32
<ljharb>
ah, i have… feelings … about RPC and SOAP and whatnot so i probably wouldn't be able to be objective :-)
18:32
<bakkot>
you can definitely do a lot of cool stuff with proxies, don't get me wrong
18:32
<Ashley Claymore>
Immer is quite popular? Thought maybe that doesn't fall under "using proxies directly"
18:32
<Jack Works>
also immer.js uses proxy too 😇
18:35
<Mathieu Hofman>
Yeah I have a half dozen use cases of Proxy that are not part of a membrane. I still find Proxy very useful, but we just need a way to be able to better reason about their hooks.
18:48
<ljharb>
right but that's just 1 maintainer, the users don't count because they don't know about proxy :-)
18:49
<bakkot>
nicolo-ribaudo I found this presentation very helpful!
18:49
<bakkot>
I have not been following all the various things and it was good to catch up
18:50
<nicolo-ribaudo>
Ok thank you! :)
19:58
<Rob Palmer>
We resume plenary in 1 minute!!!
20:15
<bakkot>
nicolo-ribaudo: question about the upcoming import.defer topic. how does the "hiding then" solution work given the "'unknown' in ns triggers evaluation" resolution from earlier in the slides?
20:17
<nicolo-ribaudo>
'then' would actually be handled like symbols and not trigger in that case (same as ns[Symbol.toStringTag] does not trigger). The idea is that wether something triggers or not depends only on the key you are checking, and not wether or not that key is exposed by the module
20:17
<bakkot>
ah, ok, so it's special-cased in the evaluation logic, not just the namespace object MOP
20:17
<bakkot>
cool
20:17
<nicolo-ribaudo>
Yes
20:18
<nicolo-ribaudo>
Well, mechanically it's special cased in the MOP, as it's the various methods that decide when to evaluate based on the key you pass them
20:18
<nicolo-ribaudo>
But yes
20:20
<bakkot>
ah, sure
20:20
<bakkot>
I do like the "hiding then" solution best of the considered options
20:27
<snek>
how is this different from subarray if the source is immutable?
20:28
<bakkot>
subarray on TAs gives you access to the full underlying buffer
20:29
<bakkot>
(and there is no subarray on ArrayBuffer)
20:31
<snek>
ok
21:00
<bakkot>
I may not be able to speak for my topic; if I'm not responding someone please read the following: "I like having a way to check if a deferred NS object is evaluated yet, but really don't like having a new well-known symbol like Symbol.evaluated for this. I'd be happier with a new global function, or a new DeferredModuleNamespace class with a static "isEvaluated" method or something. also we could add this capability in a followup; doesn't need to be included immediately if we're not sure it's worth doing."
21:09
<hax (HE Shi-Jun)>
nicolo-ribaudo: dynamic import only behave strange if then export is a function. But hiding then exclude all values.
21:09
<ljharb>
in my testing in the past, thenable ESM modules don't even work properly - meaning, can't be imported - in node (i can't remember if they fail in the repl and work outside, or the reverse, but they def didn't work in both when i tested)
21:12
<Ashley Claymore>
reading any export of a deferred namespace triggers it's evaluation, which is the issue for this proposal
21:16
<hax (HE Shi-Jun)>
Yeah, I know. I'm ok with hiding then, I just want to point out this new weirdness is not 100% same as the weirdness of dynamic import. 👾
21:16
<bakkot>
ljharb: isDeferredModuelNSEvaluated would solve this :)
21:16
<ljharb>
i saw your queue item but i don't know what that is
21:17
<bakkot>
the thing I was talking about in my item earlier
21:17
<ljharb>
ah i think i was distracted during that part then
21:17
<bakkot>
a top-level global function of that name which tells you if a deferred module NS has been evaluated already
21:17
<bakkot>
if that existed, and throws given an input which is not a deferred module NS, then it gives you the brand check you want
21:17
<ljharb>
makes sense to me.
21:21
<Michael Ficarra>
I want standard error stacks just so I can deny (read) access to the call stack in a standardised way
21:22
<shu>
i don't think we can unship the current non-standard APIs though?
21:22
<nicolo-ribaudo>
ljharb: isDeferredModuelNSEvaluated would solve this :)
Yeah this might be a nice way to sneak in the brand check. What I'm hoping for is through one of the Module methods, or maybe even as ModuleSource.isModuleNamespace is Module takes too long to come
21:22
<nicolo-ribaudo>
And I would want a brand check for either namespace, and then once you know that it's a namespace you branch on the @@toStringTag
21:23
<bakkot>
is @@toStringTag unforgeable on module namespaces?
21:25
<Michael Ficarra>
i don't think we can unship the current non-standard APIs though?
don't need to, just define them in terms of the standard API and once it's denied, they are also denied
21:26
<shu>
i don't know if that's possible?
21:26
<ljharb>
you can't change it on the namespace. but you can def make an object that fakes being a module namespace, yes
21:29
<nicolo-ribaudo>
is @@toStringTag unforgeable on module namespaces?
Yes
21:33
<ljharb>
mgaudet: what doesn't match the repo?
21:34
<mgaudet>
Are you or are you not trying to spec the textual representation?
21:34
<mgaudet>
because what you -said- sounded like no, but what the repo -says- is yes
21:35
<ljharb>
i'm trying to spec the format. not the contents.
21:35
<ljharb>
meaning, the actual text, line numbers, etc is not part of it, but the way it's put together is. all of which has been in the repo since before 2019
21:35
<mgaudet>
.... "Return the string-concatenation of the code unit 0x0020 (SPACE), ... '
21:36
<mgaudet>
isn't that the actual contents of of the frame textually represented?
21:36
<ljharb>
in the places where we know it's a number, with a colon, etc, yes, it has text
21:36
<ljharb>
but the hard part is in all the text that's not present
21:36
<ljharb>
"name", "source", etc
21:37
<ljharb>
that's the contents i'm not specifying
21:41
<Rob Palmer>
  • name
  • source
  • span
    • startPosition
      • line
      • column
    • endPosition
      • line
      • column
21:44
<Devin Rousso>
ljharb id be happy to help with the WebKit "side" of standardizing error.stack 🙂
21:55
<hax (HE Shi-Jun)>
I just realize that function name can contain any char, because people can redefine name property of a function 🤔
21:58
<ljharb>
yep. it can even be a non-string (altho it'd be stringified for the stack trace)
21:59
<ljharb>
mgaudet: filed https://github.com/tc39/proposal-error-stacks/issues/51 re "at"
22:00
<snek>
idk why we even want to specify the contents of error stack strings. structured data seems useful though.
22:03
<Devin Rousso>
FYI WebKit also uses @ https://github.com/WebKit/WebKit/blob/main/Source/JavaScriptCore/runtime/StackFrame.cpp#L161
22:04
<ljharb>
huh, did it used to?
22:04
<Devin Rousso>
pretty sure it's always been @
22:04
<snek>
yeah
22:04
<ljharb>
alrighty. i designed the spec 5-7 years ago based on research from SES, so i'm not sure how i totally missed the "@" stuff. an obvious spec bug i'll need to fix :-)
22:05
<eemeli>
As a European TC39 participant, I find skipping the "afternoon" sessions of virtual meetings much more pleasant, given that they are always based in a North American timezone, and e.g. this week we're finishing at my local midnight.
22:06
<snek>
i'm awake anyway so i don't mind these at all. its the early morning ones that kill me.
22:07
<hax (HE Shi-Jun)>
Yeah, it's good news, I can go to bed at 3am next two days.
22:07
<eemeli>
Ugh, yeah, PT at 4pm is 2am for me.
22:09
<Aki>
PSA in case you quit the meeting before I spoke up: If you're not actively reading/editing the notes, please do close that tab! (fully disregard if you're doing either activity—i'm not trying to lock them down or anything. just need to know what i'm working with.)
22:17
<Mathieu Hofman>
That's a big reason why the get stack property is in annex B in this proposal, and that the getters are static functions which could be more easily restricted
22:24
<snek>
i can understand specifying the location and attributes of the property, but idk why the string contents should be specified. in fact i kind of prefer they aren't, it would be annoying to constrain debugging.
23:00
<waldemar>
When is the May 2025 meeting? The date currently listed for it, Tuesday 2025‑05-28, does not exist — May 28 is not a Tuesday in 2025.
23:04
<nicolo-ribaudo>
It's meant to be Wed-Fri
23:59
<Rob Palmer>
It is now fixed. Thank you for highlighting Waldemar.