| 02:31 | <Mathieu Hofman> | honestly I think people may have just not noticed at the time waitAsync was being added I think you're right, it might be one of those things that slipped through. First, my understanding is that Now I'd go even further, and say there is a way to reconcile a clock API with the requirement some environments have to not allow time measurement of any sort. Let's assume a clock API is modeled like That means that without a Now of course that doesn't mean all code using a clock API would be compatible with such behavior, as some would expect consistent forward progress to continue during the wait time. I'd argue however such code would be prone to async race conditions. |
| 02:39 | <Mathieu Hofman> | And of course some programs would expect the Web behavior of setTimeout which drains the promise job queue before processing I/O jobs (which clocks are) |
| 03:28 | <shu> | Mathieu Hofman: Atomics relies on SABs only for wait and waitAsync. the rest was made to work with ABs (not that there's a way to observe that it's atomic with a single thread of execution) |
| 03:28 | <shu> | but your point still stands for wait that even if it isn't explicitly marked as normative optional, the fact that SABs can be denied makes it so in practice |
| 03:29 | <shu> | actually, i take that back |
| 03:29 | <shu> | there is a way to observe something is atomic with a single thread of execution, if you count looking at compiled code output in your model of observability, to see that there's never any unfriendly reorderings |
| 03:31 | <Mathieu Hofman> |
My model of observability is the program at runtime, so I don't think that counts? |
| 03:33 | <shu> | anyway i'm missing the broader context |
| 03:33 | <shu> | you want to add a clock API? or just thinking through the exercise? |
| 03:34 | <Mathieu Hofman> | Thinking through the exercise since people were asking why not if there is waitAsync. Also justifying why the presence of waitAsync is not such a problem |
| 03:36 | <shu> | it's not a problem for the web platform at least because the timeout value is pretty detached from wall clock time in when the promise handler gets run |
| 03:37 | <shu> | the extent to which it is it not a problem for mark is, i suspect, along the lines of what kevin said :) |
| 03:44 | <Mathieu Hofman> | Right, and I'm arguing that you can, according to the way job enqueuing is specified, offer a clock API to "schedule" future promise resolutions that does not in fact allow the program to observe time passing or how complex the code executed in-between was, as long as there is not an independent way to observe time passing. |
| 03:46 | <shu> | i'm inclined to agree at first blush |
| 15:57 | <Rob Palmer> | TC39 plenary meeting begins in two hours time. Details are here. |
| 16:51 | <yulia> | Aki: Rob Palmer bterlson hey folks -- i have someone who would like to be at the regexp set notation presentation but... they can't make it from 11 - 12... which is exactly when mattias wants to present |
| 16:51 | <yulia> | is there a chance (i know this is slim) to do it during lunch? |
| 17:02 | <bterlson> | This will not be possible unfortunately, it's a locked item and others might not be able to attend if we move it now. |
| 17:09 | <yulia> | ok, no problem, thanks! |
| 17:34 | <Rob Palmer> | if anyone feels like being the first guinea pig to try the sign-in process and meeting password, please follow the link in the reflector post. and let me know how it goes - I am in the room. And a reminder: please don't post the URLs to anything privileged here like the sign-in form - it gets logged! Only the Reflector post is safe. |
| 17:35 | <jschoi> | I already did the form, and it seemingly worked for me. |
| 17:36 | <Rob Palmer> | Nicolo has proven the sign-in works! |
| 17:48 | <nicolo-ribaudo> | When will the next meetings be added to the calendar? |
| 17:52 | <ljharb> | the google calendar? i can add them now |
| 17:52 | <nicolo-ribaudo> | Yes that one, thanks! |
| 17:57 | <Rob Palmer> | We are starting the meeting in 3 minutes. So far 13 people have joined. |
| 18:00 | <ljharb> | nicolo-ribaudo: calendar's updated with all scheduled dates. lmk if you (or anyone) wants to be added to the event so it pops up automatically on your own calendar |
| 18:03 | <Robin Ricard> | No bot, no note takers |
| 18:04 | <Robin Ricard> | ot active thanks bakkot |
| 18:04 | <ljharb> | Aki: it's now 1.5 hours (i updated the draft schedule to remove an item that was deferred on the agenda) |
| 18:05 | <rkirsling> | Rob Palmer: ironically, your display name is just an email address :P but it does make the affiliation clear |
| 18:06 | <rkirsling> | * . |
| 18:10 | <rkirsling> | always is amusing how recognizable everyone is in kid form |
| 18:14 | <bterlson> | Nostalgia: that computer I was using was a pentium 150MHz overclocked to 166MHz with dual voodoo 2 graphics cards |
| 18:15 | <rkirsling> | I once had a voodoo 2, but it was in a PowerPC |
| 18:23 | <rkirsling> | good clap UI |
| 18:23 | <bterlson> | lol the clapping crashed my browser |
| 18:26 | <bakkot> | excellent clapping ui, if you clap hard enough it causes audience members to pass out |
| 18:38 | <bterlson> | Way to go editors, these changes are really cool. Love to see more "spec as an app" features. |
| 18:39 | <shu> | get ready for launch of ecma262+ |
| 18:40 | <Michael Ficarra> | bterlson: can't wait to show you what the research group from KAIST has been working on at the next meeting |
| 18:40 | <rickbutton> | very excited for that Michael Ficarra |
| 18:40 | <bterlson> | Coming in 2022: meta262 |
| 18:40 | <Michael Ficarra> | among other things ,they are generating a reference implementation from the spec |
| 18:40 | <bterlson> | bterlson: can't wait to show you what the research group from KAIST has been working on at the next meeting |
| 18:40 | <shu> | does the ecma IPR prohibit TCs from charging for premium subscriptions |
| 18:41 | <ryzokuken> | would folks be interested in a #test262:matrix.org room in this space? |
| 18:41 | <ljharb> | bterlson: fwiw i refreshed and it still says test262 status |
| 18:42 | <bterlson> | it was on that item |
| 18:42 | <bterlson> | rob was a few items back |
| 18:43 | <bterlson> | everyone should see that we're on item 7 |
| 18:46 | <ljharb> | looks good to me now, thanks |
| 18:48 | <bterlson> | It feels like Rob's websocket got dropped. I blame Bloomberg's firewall. |
| 18:51 | <Rob Palmer> | i'm not behind a firewall! |
| 18:52 | <bterlson> |
|
| 19:17 | <Michael Ficarra> | what's wrong with setting a precedent of not changing the meaning of \d, \w, and \b? |
| 19:17 | <Michael Ficarra> | I think that's the right precedent to set |
| 19:18 | <jschoi> | I recall that Perl 6 / Rakudo includes escape sequences for both ASCII digits, word characters, etc. and full-Unicode digits, word characters, etc.—in the same regex mode. |
| 19:18 | <jschoi> | And maybe Perl 5 now too. |
| 19:19 | <bakkot> | for the notes, who's speaking? |
| 19:19 | <bakkot> | apparently MDS, thanks to whoever put that in |
| 19:21 | <Michael Ficarra> | nope, it is MED (Mark E Davis) |
| 19:21 | <Michael Ficarra> | MDS isn't assigned to anyone |
| 19:21 | <Robin Ricard> | updating my delegates.txt pr |
| 19:21 | <bakkot> | I feel like JS people generally don't assume things will change out from under them |
| 19:22 | <Michael Ficarra> | tip for note takers: if you don't know an abbreviation, just leave it empty or write the full name until we get the right one |
| 19:22 | <jschoi> | Is there precedent for “stability policies” in the spec? |
| 19:22 | <jschoi> | Like https://www.unicode.org/policies/stability_policy.html, but for Ecma-262. |
| 19:23 | <bakkot> | the policy is "we won't break the web" |
| 19:23 | <bakkot> | no more, no less |
| 19:23 | <jschoi> | Yeah, so no precedent for formal stability policies. |
| 19:23 | <bakkot> | yeah |
| 19:23 | <jschoi> | I figure that Mark Davis is coming from that sort of Unicode-stability-policy mindset. |
| 19:24 | <jschoi> | Just guessing though. |
| 19:24 | <Michael Ficarra> | the presence of a stability policy implies there is some instability somewhere |
| 19:25 | <bakkot> | there is, sometimes we add new properties to things and somethings that breaks things |
| 19:25 | <bakkot> | if we could say "please do not assume the absence of properties on built-ins" that would be nice |
| 19:25 | <bakkot> | but it's not really a policy because we'll still back things out if someone does |
| 19:26 | <Michael Ficarra> | sounds like 100% stability (modulo observability) to me |
| 19:27 | <bakkot> | sometimes we're still willing to break stuff if it's only a small fraction of things or the need is sufficiently great, though |
| 19:27 | <jschoi> | Related from HTML’s side of not breaking the web: https://matrixlogs.bakkot.com/WHATWG/2021-11-11#L29 |
| 19:27 | <bakkot> | e.g. we backed out SAB |
| 19:27 | <jschoi> | Like extending addEventListener’s third argument and XMLHttpRequest’s send. |
| 19:28 | <jschoi> | Also see also https://github.com/tc39/proposal-bigint-math/issues/17#issuecomment-966426554. |
| 19:29 | <jschoi> | Then again, smooshgate. Anyways, no Unicode-style formal stability policy right now…and maybe there can’t be. |
| 19:30 | <bakkot> | yeah, there can't be, really |
| 19:33 | <Michael Ficarra> | RIP smooshMap, the best method name ever |
| 19:37 | <bakkot> | you have write access to 262, you could make it happen |
| 19:38 | <bterlson> | Rick Waldron: are you ready to go with shadow realm after Array Grouping? |
| 19:38 | <bterlson> | we may have enough time to fit in a 10 minute item |
| 19:44 | <rbuckton> | groupByIntoMap? |
| 19:44 | <TabAtkins> | Justin Ridgewell: having the README contain at least a skeleton of all the proposed methods would be nice, as would having a link to the rendered spec in the README. I didn't realize groupByMap() was in the proposal at all. |
| 19:45 | <TabAtkins> | groupForByIntoOverMap |
| 19:45 | <Kris Kowal> | I like *ToMap on the toString precedent |
| 19:47 | <bakkot> | oh, toString is a great example |
| 19:47 | <rbuckton> | groupBy(..., collector) where collector is something like { create(), add(...), finish() }? I think it was considered and abandoned (or delayed) by the iterator helpers proposal. |
| 19:48 | <rbuckton> | Or groupBy(...) -> GroupedIterator where GroupedIterator has .toObject(), .toMap() and is iterable for [key, values] |
| 19:50 | <TabAtkins> | I don't think the default function being an indirection object would be good, but we can extend the method to allow a collector later. |
| 19:52 | <Michael Ficarra> | rbuckton: https://matrixlogs.bakkot.com/TC39_Delegates/2021-08-31#L558-L561 |
| 19:53 | <Michael Ficarra> | rbuckton: I plan to introduce a proposal for a builder protocol, and it will be pull, not push, for that reason |
| 19:53 | <rbuckton> | A Map builder is essentially new Map(iterable) though? |
| 19:54 | <Michael Ficarra> | yes because Map is simple |
| 20:04 | <bakkot> | Rick Waldron: deleted my queue item, it was "sounds good as a follow up, want to confirm no compat risk because it's not primitive" - just want to confirm that trying to share a SAB right now will necessarily throw |
| 20:05 | <shu> | yeah |
| 20:05 | <shu> | like any other non-callable object |
| 20:05 | <shu> | so what you want is to wrap your SAB in a callable proxy! |
| 20:06 | <Rick Waldron> | Rick Waldron: deleted my queue item, it was "sounds good as a follow up, want to confirm no compat risk because it's not primitive" - just want to confirm that trying to share a SAB right now will necessarily throw |
| 20:45 | <ljharb> | Justin Ridgewell: did you delete that twitter account you made once upon a time? |
| 20:56 | <Justin Ridgewell> | Shhh, I don't have a twitter. |
| 20:57 | <Justin Ridgewell> | I use that for DMs at conferences and lurking only, I never post. |
| 20:58 | <Rick Waldron> | bterlson: in the future, you could go with a 4 minute warning. https://www.youtube.com/watch?v=6eyUrpOl40k |
| 20:59 | <ljharb> | Shhh, I don't have a twitter. |
| 21:01 | <Justin Ridgewell> | I've seen some just use my real name when tweeting, but don't feel like you need to credit me |
| 21:01 | <Justin Ridgewell> | Essentially I only recognize my GH handle as a public account |
| 21:01 | <ljharb> | real names aren't as idiomatic and quippy ¯\_(ツ)_/¯ |
| 21:04 | <ljharb> | msaboff: can you mute jitsi? |
| 21:14 | <ljharb> | i'd prefer it go in "notational conventions" or something, so it's in the actual spec |
| 21:35 | <ljharb> | what is the "m" in "Chrome m99"? |
| 21:37 | <jschoi> | I will note that “documenting invariants” is sort of formally stating something about stability in the specification. Although it’s not quite as all-encompassing as a Unicode-style full stability policy. |
| 21:38 | <ljharb> | sffc: is that wind chimes? |
| 21:43 | <sffc> | yeah, sorry, is it too loud? I'm sitting outside and it's windy |
| 21:43 | <yulia> | jschoi: would you be ready to go next? |
| 21:43 | <ljharb> | yeah, sorry, is it too loud? I'm sitting outside and it's windy |
| 21:44 | <yulia> | also ptomato would you be ready after? |
| 21:44 | <ptomato> | sure, I think I can make that work |
| 21:45 | <yulia> | ill just wait to see if jschoi is ready as the next presenter... else i might rely on you going really soon |
| 21:46 | <jschoi> | yulia: I am ready. |
| 21:46 | <yulia> | cool |
| 22:01 | <Kris Kowal> | The measure of my support for Array.fromAsync is that I hope it gets to stage 4 as fast or faster than Error cause :-) |
| 22:05 | <bakkot> | whoops, posted in the wrong channel, but |
| 22:05 | <bakkot> | there is no Set.from or Map.fromEntries |
| 22:06 | <ljharb> | Mathieu Hofman: it awaits the entry, why would it await either the key or the value (ie, it would take in an async iterable of entries) |
| 22:06 | <bakkot> | that is not obviously the right thing, to me |
| 22:07 | <Mathieu Hofman> | Awaiting an entry would rarely be valuable |
| 22:07 | <ljharb> | all the more reason to have it be a separate proposal :-) |
| 22:07 | <Mathieu Hofman> | awating a value would more often be useful, but I've heard of use cases wanting to await the key as well |
| 22:09 | <Mathieu Hofman> | agreed, and that's why I wanted to avoid looping in anything entries related in this proposal, too many questions to resolve |
| 22:10 | <bakkot> | my laptop just crashed |
| 22:10 | <bakkot> | so notes bot is down |
| 22:10 | <ljharb> | https://github.com/tc39/proposal-setmap-offrom (cc erights ) |
| 22:13 | <yulia> | Justin Ridgewell: |
| 22:13 | <yulia> | are you available to go next? |
| 22:13 | <Justin Ridgewell> | Sure |
| 22:14 | <Justin Ridgewell> | When does today's session end? |
| 22:14 | <Michael Ficarra> | 46 minutes |
| 22:15 | <bakkot> | notes bot should be back up |
| 22:15 | <yulia> | nicolo-ribaudo: do you still need morre note takers? |
| 22:15 | <nicolo-ribaudo> | No, it's working now! |
| 22:15 | <yulia> | cool |
| 22:22 | <Kris Kowal> | The time of the Temporal proposal has changed, and the slides are arriving after they’re presented. Coincidence!? 🤔 |
| 22:24 | <bakkot> | wait, instant doesn't require a timezone? I know it doesn't carry one, but doesn't instant need to know the offset in the string to figure out what instant it actually represents? |
| 22:24 | <bakkot> | I guess I can go read the docs... |
| 22:30 | <yulia> | aight, who else wants to go next, chris garrett ? or rbuckton ? |
| 22:30 | <yulia> | I don't know if chris is in this chat.. |
| 22:30 | <ptomato> | bakkot: it requires a "Z" or a UTC offset like "+03:00" but it doesn't require a name |
| 22:30 | <yulia> | so, rbuckton would you be able to fill the last 15 min? |
| 22:31 | <rbuckton> | I can go. |
| 22:31 | <yulia> | great, thank you |
| 22:31 | <bakkot> | ptomato: I think the example in the slides was 2021-12-14T10:00[Mars/Olympus_Mons] which has neither, no? |
| 22:31 | <bakkot> | or maybe the parser in my head is broken |
| 22:31 | <bakkot> | or I misread |
| 22:32 | <bakkot> | oh, it's on the slide twice, and the second time has a Z |
| 22:32 | <ptomato> | oh, let me double check |
| 22:32 | <bakkot> | ok |
| 22:34 | <ptomato> | ah, right, 2021-12-14T10:00[America/Vancouver] without Z or UTC offset is a valid string for ZonedDateTime, meaning "that wall-clock time in that time zone". but it is not valid for Instant |
| 22:35 | <bakkot> | and contrariwise 2021-12-14T10:00[Mars/Olympus_Mons] without Z is valid for... I guess PlainDateTime? but neither ZonedDateTime (because unknown time zone) or Instant (because no Z or known time zone) |
| 22:35 | <bakkot> | I was just confused by it being different in the two places it appeared on the slide |
| 22:35 | <bakkot> | wait, three places |
| 22:35 | <ptomato> | correct |
| 22:41 | <danielrosenwasser> | 👍 with how confusing cover grammars are to understand during implementation |
| 22:42 | <bakkot> | cover grammars are closer to how you'd implement though, I think |
| 22:42 | <bterlson> | I feel like the cover grammar is useful for implementers, otherwise you don't know what to speculatively parse to avoid unbounded lookahead? What syntax is valid in the cover feels hard and possibly error prone to recover given just a token to lookahead for? |
| 22:42 | <danielrosenwasser> | Depends on the implementation |
| 22:42 | <bakkot> | does anyone have an implementation which is not recursive descent? |
| 22:42 | <yulia> | we have the parser generator to a table but we aren't shipping it |
| 22:43 | <yulia> | our production parser is recursive descent |
| 22:43 | <danielrosenwasser> | So IIRC, for our object literals we do a cover grammar implementation, and for arrow functions we use a speculative parse / unbounded lookahead |
| 22:43 | <danielrosenwasser> | But we are not an engine team |
| 22:44 | <nicolo-ribaudo> | Babel uses a cover gammar both for objects and for arrows. Being able to follow the spec helps with implementation correctness. |
| 22:44 | <bakkot> | danielrosenwasser: is your impl public? I'd enjoy looking at it probably |
| 22:44 | <danielrosenwasser> | danielrosenwasser: is your impl public? I'd enjoy looking at it probably |
| 22:44 | <danielrosenwasser> | it's gross and awful |
| 22:44 | <shu> | danielrosenwasser: i specifically didn't say engine team for that reason :) |
| 22:44 | <danielrosenwasser> | https://github.com/microsoft/TypeScript/blob/main/src/compiler/parser.ts |
| 22:44 | <bakkot> | I chose to be maintainer of the JS spec, I like gazing into the abyss :P |
| 22:47 | <danielrosenwasser> | https://github.com/microsoft/TypeScript/blob/main/src/compiler/parser.ts#L4502 This is the start of the abyss. Keep in mind we have to parse out annotations |
| 22:47 | <danielrosenwasser> | Feel free to DM me complaints |
| 22:47 | <bakkot> | oh I've read this before |
| 22:48 | <bakkot> | I forget why |
| 22:48 | <bterlson> | parser.ts is hardly an abyss |
| 22:48 | <bterlson> | I mean, if it is, I don't know what that makes checker.ts |
| 22:49 | <danielrosenwasser> | I forget why |
| 22:50 | <bakkot> | yeah I've filed a few bugs with the parser |
| 22:51 | <danielrosenwasser> | I mean, if it is, I don't know what that makes checker.ts |
| 22:52 | <danielrosenwasser> | Ctrl+F any function name you need and you immediately find it |
| 22:52 | <danielrosenwasser> | (quarter-joking) |
| 22:53 | <yulia> | this sounds like my workflow |
| 22:55 | <shu> | a ridiculous workflow i actually like is jumping-to-definition ecma262 source: Ctrl+F AbstractOperationName<space>( |
| 22:56 | <danielrosenwasser> | it would be nice if the spec had an easy way to Ctrl+F in specific ways for this |
| 22:57 | <shu> | in the rendered version, you mean? |
| 22:57 | <yulia> | i find the above is really useful -- i use it all the time as well |
| 22:57 | <danielrosenwasser> | Yeah - I don't want to load the page, but IIRC abstract operations don't have an easy way to Ctrl+F similarly |
| 22:57 | <shu> | yeah that'd be nice |
| 22:57 | <shu> | though the searchbar is pretty good |
| 22:58 | <ptomato> | I was just thinking the other day that a keyboard shortcut to jump focus to the searchbar would be nice |
| 22:58 | <yulia> | wait doesn't tab work? |
| 22:59 | <bakkot> | / |
| 22:59 | <ptomato> | so it does! |
| 22:59 | <danielrosenwasser> | /! TIL |
| 22:59 | <danielrosenwasser> | Don't know why I didn't think to try that |
| 22:59 | <ptomato> | apparently I should've just asked here earlier 😛 |
| 22:59 | <yulia> | oh nice, / |
| 23:00 | <shu> | there is a sliver of truth in what Ron says about some things being obscure and consistent cross-languages. in my wheelhouse, memory ordering names mean more or less the same thing |
| 23:01 | <shu> | whether that applies to regular expressions though, my hunch is no? |
| 23:08 | <rbuckton> | Thinking about the number of times I've written a RegExp with (?:\r\n?|\n), how that's missing the other line terminator cases, and how that'll still be easier to type than \p{NewLine_Sequence}. Even if we had \p{NewLine_Sequence}, I feel line terminators are common enough that having \R as a shorthand would be preferable. |
| 23:08 | <jschoi> | I will say that newline sequences are pretty common in my code too. |
| 23:11 | <bakkot> | if the thing you want is to match (?:\r\n?|\n), surely you'd write that, rather than \R? \R means a different thing which readers have to learn; I would think you'd only use it when you actually wanted that other thing explicitly |
| 23:12 | <rbuckton> | That's why I said "how that's missing the other line terminator cases". Only matching CR, LF, CRLF isn't very unicode friendly. |
| 23:13 | <rbuckton> | TR18 specifies what characters should match RL1.6 Line Boundaries, and strongly recommends "that there be a regular expression meta-character, such as "\R", for matching all line ending characters and sequences" https://www.unicode.org/reports/tr18/#Line_Boundaries |
| 23:14 | <nicolo-ribaudo> | It also happened to me to forget about the two other line terminators, or to review PRs where they have been forgotten (example: https://github.com/babel/babel/pull/10884#pullrequestreview-333658177) |
| 23:15 | <rbuckton> | I can look into how to request the addition of a sequence property for this, though the Unicode standard recommends using \R |
| 23:16 | <nicolo-ribaudo> | (I don't have a proper opinion yet regarding \R vs \p{...}, but I agree that it would be nice to solve this in the language) |
| 23:24 | <bakkot> | nicolo-ribaudo: to be clear, neither \R or a hypothetical \p{newline_sequence} would actually correspond to JS newlines, since unicode line terminators include \v and \f |
| 23:24 | <nicolo-ribaudo> | Oh thanks, I missed it |
| 23:25 | <rbuckton> | nicolo-ribaudo: to be clear, neither |
| 23:26 | <bakkot> | I mean to say that in the PR linked it was JavaScript code |
| 23:26 | <nicolo-ribaudo> | In my specific example it was |
| 23:26 | <rbuckton> | Ah, I misunderstood. |
| 23:36 | <rbuckton> | It looks like support for sequence properties will require v mode, while \R would only require u |