2021-06-01

2021-06-02
[14:33:00.0914] <shu>
bakkot: Michael Ficarra meeting?

[16:16:51.0044] <shu>
domenic requested our review on https://github.com/heycam/webidl/pull/987, btw

[16:17:12.0834] <shu>
i'm looking at it now, don't think additional sets of eyes are necessary, but feel free to if you have spare cycles


2021-06-03

2021-06-04

2021-06-05

2021-06-06

2021-06-07

2021-06-08

2021-06-09
[09:41:21.0567] <Michael Ficarra>
thoughts on using Kleene star in the 262 grammar?

[09:41:37.0798] <Michael Ficarra>
I think only Allen and Waldemar ever cared about avoiding its use

[09:42:15.0124] <shu>
i don't mind it, why have they opposed it in the past?

[09:46:30.0692] <Michael Ficarra>
I think it was easier to confirm some grammar property they were trying to preserve?

[09:46:42.0766] <Michael Ficarra>
not totally sure, it's been a loooooong time since that's been discussed

[10:52:09.0072] <shu>
what is a place where you want to use *?

[13:49:32.0242] <bakkot>
I don't think it would be enough of an improvement to warrant the overhead of the change


2021-06-10

2021-06-11
[11:42:36.0577] <Michael Ficarra>
so, thoughts on the Kleene star/plus

[11:42:56.0999] <Michael Ficarra>
there's definitely tons of opportunities to apply it, and I do feel it would make things more readable

[11:43:01.0203] <Michael Ficarra>
BUT

[11:43:38.0064] <Michael Ficarra>
we would need a way to do grouping if we wanted to fully eliminate some of the productions, which I don't really want to introduce

[11:43:56.0696] <Michael Ficarra>
and there will be *so much churn* in rewriting/refactoring SDOs

[11:44:36.0400] <Michael Ficarra>
I don't want the Kleene star badly enough to sign up for all that work

[11:50:17.0920] <Michael Ficarra>
we could make Annex A a little more useful by adding Kleene star, grouping, disjunction, etc., but that also might make it harder to modify in conjunction with the main body as new features are added

[11:55:41.0368] <bakkot>
better for Annex A to match the main grammar, I think

[14:41:05.0782] <shu>
yes, that Annex A should match is more important

[14:41:20.0284] <shu>
it should always be obviously just the grammar copy/pasted and collected in one place


2021-06-12

2021-06-13

2021-06-14

2021-06-15

2021-06-16

2021-06-17
[19:51:29.0101] <bakkot>
Michael Ficarra: you broke #2109

[19:51:32.0243] <bakkot>
check the diff


2021-06-18

2021-06-19

2021-06-20
[15:22:09.0470] <bakkot>
shu: can abstract closures write to the aliases they capture, do you figure?

[15:29:58.0720] <bakkot>
the answer appears to be "no":
> When an Abstract Closure is created, it captures the value that is associated with each alias at that time.


2021-06-21

2021-06-22

2021-06-23
[11:24:33.0877] <shu>
bakkot: yes, we made the decision back then that they're capture-by-value

[11:24:40.0930] <shu>
since aliases, are, well, aliases, and not bindings

[11:25:01.0416] <shu>
if we come up with storage for algorithm steps, we could, but the work around is to allocate records that you use as boxes


2021-06-24
[22:02:44.0779] <bakkot>
anyone else want to review https://github.com/tc39/ecma262/pull/2260, or shall we just land it?

[09:14:02.0251] <shu>
i certainly do not want to review, happy to defer


2021-06-25

2021-06-26

2021-06-27

2021-06-28

2021-06-29

2021-06-30
[15:17:07.0094] <shu>
oh i completely forgot we were going to test the "invitees don't need to ask to join" theory

[15:17:10.0368] <shu>
let me make a new calendar item now

[15:19:25.0611] <shu>
bakkot: are you logged into a google account on your shape email?

[15:22:18.0654] <bakkot>
uhhhhh that's kind of complicated. basically no

[15:24:27.0615] <shu>
okay, then the experiment is probably not even worth trying

[15:24:38.0842] <shu>
the only way i can imagine it working is if you're logged in as the invited email address