TC39 Delegates
2024-04-25
plaintext logs
prev next
source on github
00:50
<rkirsling>
right
00:50
<rkirsling>
I feel like that status doesn't really warrant a separate term but yeah
03:03
<littledan>
I am seeing both stories represented in this chat (“stage 0 is not an actual thing that makes sense to think about criteria for” vs “stage 0 is when we have a real potential proposal, eg with a champion lined up”). There isn’t an agreed-on answer, even if your own interpretation seems obviously correct to you. I think we should make a shared decision on which interpretation we all take. A third option is to discourage the use of the term.
03:06
<littledan>
This is just a random one of several process points we have where there are multiple interpretations going around among long-time delegates. “Can IEs block” has long been another. I mean this in a neutral way: different understandings simply do exist; I am not advocating for one or the other position.
03:11
<ljharb>
that's true about "ship at stage 3", too. but the way things have mostly always been done in practice is usually the thing we should clear up misunderstandings about.
03:17
<littledan>
Right it was complicated and slow to build consensus around that, and the result is not 100% unambiguous even now. I think the currently reality is slightly more like, Stage 3 plus (in certain complicated cases) some intangible confidence is when things ship; I hope we can move more towards more consistently having that confidence when something becomes Stage 3, and the recent 2.7 addition helps towards that goal.
03:22
<ljharb>
indeed, "what thing actually mean" is often more complex than can be easily explained, or than is documented. but it's empirically deriveable, for all the things you've mentioned - there's only one current correct understanding. we can and should improve documentation when there's confusion, and we always can discuss changing what things mean if we think there's a better way.
03:23
<littledan>
I think these are exercises in consensus-building, not uncovering and documenting the real truth.
03:23
<ljharb>
both are part of it
03:23
<ljharb>
the meaning of a thing doesn't change just because someone comes up with a different understanding of it, unless that different understanding becomes what the committee empirically follows.
03:26
<littledan>
Often both precedent and historically intended meanings are ambiguous. We can work through this by gradually building consensus on what should be our way of working.
03:27
<ljharb>
i agree. but imo we can't build that consensus unless misunderstandings about how we have been working get cleared up.
03:27
<littledan>
Sure but making strong assertions on one side or the other doesn’t necessarily clarify things
03:27
<ljharb>
for example, IEs empirically have blocked, ∴ they can block. if someone thinks they shouldn't be able to block, let's build consensus around changing that
03:29
<littledan>
When blocks occur, it can sometimes be ambiguous what is going on, eg what the rationale is, who did the block, or whether the champion just voluntarily decided to withdraw the proposal from consideration for advancement. I am glad we are working more on clarifying note-taking in this area.
03:30
<littledan>
A lot of times the committee carefully works at the intersection of many people‘s interpretations of process
03:30
<ljharb>
indeed. and that becomes much more complex when new and different understandings materialize, which is why correcting those is beneficial.
15:26
<Chris de Almeida>
epistemology is hard
15:33
<Chris de Almeida>
a lot of good points have been made. I think it's important to proceed a bit cautiously, at the risk of overcorrecting with solutions to non-problems. in other words, I am a lot more interested in solving for things like "what should delegates/IEs do when creating a proposal repo" and not as much in more abstract things like "what is the meaning of stage 0"
15:39
<Chris de Almeida>
I should have worded the last bit better. it's important to have a shared understanding of what stage 0 means. further qualifying what is or is not stage 0 based on some criteria is only useful as far as it is practically relevant
15:53
<Chris de Almeida>
for example, if we added entrance criteria for stage 0, such as "there must be a champion", how is this valuable or materially different than the status quo? a champion is needed for the proposal to progress to stage 1 (and beyond) anyway. so adding this (or probably any entrance criteria) to stage 0 doesn't help anything, and it introduces a new problem: what to call non-stage 0 proposals. you effectively introduce a new stage, and to what end?
17:52
<keith_miller>
What do folks think about recommending web authors put the value/done properties on the iterator object directly and return this (aka the iterator itself) from next rather than return a fresh object each iteration loop? This, I think, should improve the performance of their iterators as they're not allocating fresh objects all the time. Is this a compatibility breaking change we should look into for built-in iterators too?
17:54
<keith_miller>
Given there's been a lot of debate about the performance of the iterator protocol on a bunch of recent proposals I'm trying to brainstorm solutions.
17:57
<shu>
are you saying as a new protocol?
17:58
<keith_miller>

No, as in you'd do

function makeRangeIterator(start = 0, end = Infinity, step = 1) {
let iterationCount = 0;

const rangeIterator = {
// It's recommended that iterators attach their value and done properties to the
// iterator itself rather than return a new object every time (e.g. via `return { value: ..., done: ... }`)
// as a performance optimization.
value: start,
done: false,
next() {
if (nextIndex \< end) {
this.value += step;
iterationCount++;
return this;
}

this.value = iterationCount; // Nit: This isn’t read so I don’t know why it’s here
this.done = true;
return this;

},
};
return rangeIterator;
}
17:59
<shu>
ooh
17:59
<shu>
that certainly has a higher chance of being compatible but i still don't know how we find out other than "ship and see"
18:00
<keith_miller>
Yeah, fair enough
18:00
<shu>
otherwise i mean, yeah, i like it for the obvious reasons
18:01
<keith_miller>
It also seems like we should recommend having done/value as the first two properties on your iterator so they don't blow out your ICs. But I don't know if engines all have the same behavior there so that's a bit more controversial
18:02
<bakkot>
I would make it a seperate object and re-use it
18:03
<keith_miller>
That's fine too although I guess slightly less efficient. But might be more likely compatible.
18:03
<keith_miller>
I suppose it also better avoids the done/value blowout problem
18:04
<bakkot>
In practice I don't think people are implementing iterators themselves much, rather than using generators
18:05
<keith_miller>
Yeah, probably. I suppose this same concept could be applied to generators. I have less of an idea on whether we can change that behavior...
18:05
<shu>
It also seems like we should recommend having done/value as the first two properties on your iterator so they don't blow out your ICs. But I don't know if engines all have the same behavior there so that's a bit more controversial
V8 has a lot of complexity for fast-path checks for the shape of the iterator result object
18:06
<shu>
(we have a canonical map that's the same as if you wrote an object literal {value, done} and check against that)
18:06
<keith_miller>
Gotcha, I think we treat them the same as any other IC
18:07
<shu>
oh in user code we treat them the same as any other IC
18:07
<shu>
but in our built-ins we have all these checks
18:07
<keith_miller>
Ah ok
18:18
<bakkot>
It would be pretty weird, conceptually, for generators and built-in iterators to re-use their result object for each yielded value.... but I would be kind of surprised if it actually breaks anything? Holding onto the { done, value } pair is a very strange thing to do
18:28
<keith_miller>
That's kinda why I was thinking that the iterator would return itself and have own done/value because it feels conceptually less weird but I'll take either solution.
18:40
<littledan>
a lot of good points have been made. I think it's important to proceed a bit cautiously, at the risk of overcorrecting with solutions to non-problems. in other words, I am a lot more interested in solving for things like "what should delegates/IEs do when creating a proposal repo" and not as much in more abstract things like "what is the meaning of stage 0"
I agree completely; that's the question from Tab that started all of this! I think I focused on less important things above, got off on a tangent.
18:41
<littledan>
for example, if we added entrance criteria for stage 0, such as "there must be a champion", how is this valuable or materially different than the status quo? a champion is needed for the proposal to progress to stage 1 (and beyond) anyway. so adding this (or probably any entrance criteria) to stage 0 doesn't help anything, and it introduces a new problem: what to call non-stage 0 proposals. you effectively introduce a new stage, and to what end?
this is a good question to ask people who believe that the status quo already contains what you're describing as far as the entrance criteria. It'd be nice to disambiguate this stuff, but yes definitely less important than practical how-to advice.
18:42
<littledan>
I agree completely; that's the question from Tab that started all of this! I think I focused on less important things above, got off on a tangent.
in particular, if our answer is, "you can do whatever you want!" for things where we really should be suggesting something concrete, thereby setting people up for some future criticism, we're giving suboptimal advice.
18:50
<Chris de Almeida>
you're absolutely right; we should set those expectations
18:51
<Chris de Almeida>
sometimes we've set them already and short-term memories get the best of us.. like I'm realizing and thinking to myself "why are we talking about champions at stage 0" when a champion is a clear entrance criterion for stage 1 and is well-documented
18:52
<littledan>
multiple people said above they believed it was self-evident that there is that requirement. While this issue isn't very important, it might be a nice easy one to start with as we untangle differing beliefs about what our process is.
18:54
<Chris de Almeida>
certainly. in matters where we have a Source of Truth™️, we can reference that when people have conflicting views. that should resolve. if people want to change what the process/guidance is, that's ok too, but that should at least clear up what the current state is
20:26
<shu>
man, this language
20:27
<shu>
%TypedArray%.from(array) on JS arrays caches the entire input array ahead of time because it treats it as an iterable %TypedArray%.set(array) on JS arrays does not cache the input array ahead of time because it treats it as an array-like
20:43
<TabAtkins>
for example, if we added entrance criteria for stage 0, such as "there must be a champion", how is this valuable or materially different than the status quo? a champion is needed for the proposal to progress to stage 1 (and beyond) anyway. so adding this (or probably any entrance criteria) to stage 0 doesn't help anything, and it introduces a new problem: what to call non-stage 0 proposals. you effectively introduce a new stage, and to what end?
Right, I don't think we need anything additional stage-wise. I think it's perfectly fine to treat all early proposals as 0, regardless of their quality/championship/etc. I just ran into the "when does the proposal get put into the tc39 repo" question, which was unclear and is a little inconsistent currently.
20:44
<TabAtkins>
I think a rule of "it's definitely moved when the proposal is stage 1; it can be moved, at the champion's discretion, when a stage 0 proposal is intended for presentation at a meeting" sounds reasoanble and appears to match consensus?
20:44
<TabAtkins>
Tho also the criteria listed in https://github.com/tc39/proposals/blob/main/stage-0-proposals.md are stricter than "any idea you write down".
20:45
<Chris de Almeida>
Tho also the criteria listed in https://github.com/tc39/proposals/blob/main/stage-0-proposals.md are stricter than "any idea you write down".
my understanding is those criteria are required to be listed on that md, but that should be made clear, for all the reasons above
20:47
<TabAtkins>
Ah, that sounds reasonable, I can PR some wording
21:14
<littledan>
I think a rule of "it's definitely moved when the proposal is stage 1; it can be moved, at the champion's discretion, when a stage 0 proposal is intended for presentation at a meeting" sounds reasoanble and appears to match consensus?
IMO we should adopt the simpler version, “the tc39 org includes just Stage 1+ things” and adopt the interpretation “stage 0 isn’t really a thing, just some silly turn of phrase with no meaning in committee”.
21:15
<TabAtkins>
This would also be fine with me (but we do have some Stage 0s in the org currently, so they'd have to eitehr be ejected or grandfathered)
21:15
<littledan>
This would also be fine with me (but we do have some Stage 0s in the org currently, so they'd have to eitehr be ejected or grandfathered)
Agreed (and I would vote eject after the champions have some time to propose for stage 1)
21:15
<ljharb>
i'm pretty sure disallowing stage 0's in the org would not be inline with ecma's archival desires
21:15
<ljharb>
if anything i'd think they'd want all stage 0's to be in the org
21:16
<TabAtkins>
Well, not all, random people propose "stage 0" things as well.
21:16
<TabAtkins>
Before ever getting a champion.
21:16
<littledan>
i'm pretty sure disallowing stage 0's in the org would not be inline with ecma's archival desires
Could you elaborate on this? Aki is working on improving our archival stuff so collecting all requirements will be useful.
21:17
<littledan>
Well, not all, random people propose "stage 0" things as well.
Sure, random people say they are proposing things, but is it really at stage 0? OTOH did they establish precedent? More epistemology.
21:20
<Chris de Almeida>
Could you elaborate on this? Aki is working on improving our archival stuff so collecting all requirements will be useful.
at the point the committee discusses a proposal, that discussion and the proposal are subject to archiving. having that proposal outside of the org makes that messy, and subject to additional risk of tampering
21:20
<Chris de Almeida>
having it in the org isn't a panacea, but it goes a long way
21:22
<littledan>
Interesting, I don’t think we have been consistent about transferring all presented proposals, have we been?
21:22
<TabAtkins>
No, I don't think so - the list of Stage 0 proposals, at least, only has one presented Stage 0 in the org; the rest are still in personal repos.
21:25
<littledan>
What if we add all presented repos to a list to be archived?
21:25
<littledan>
Which sort of tampering are we concerned about?
21:26
<ljharb>
someone can delete their github account, for example
21:26
<ljharb>
or a repo
21:26
<littledan>
Right, this is the point of archiving
21:27
<littledan>
I don’t know if we have a functional archival system at the moment, but if we did, what would we want it to do?
21:27
<ljharb>
we certainly haven't transferred everything that's been presented and not gotten stage 1, but that'd be a good thing to do.
21:28
<ljharb>
clone all the repos, back up all the issue and PR and wiki content, i suppose? like a "web archive" of it all
21:28
<littledan>
Are there reasons in addition to archival why we should do this transfer?
21:28
<ljharb>
it's better for history and research and whatnot.
21:28
<ljharb>
but that's why it's been ad hoc, because it's depended on the circumstances.
21:28
<ljharb>
(which has been fine so far)
21:28
<littledan>
clone all the repos, back up all the issue and PR and wiki content, i suppose? like a "web archive" of it all
Yeah let’s think about what functionality we want from the archive. I like your idea because it would be accessible from the web rather than just a mysterious Ecma server
21:29
<ljharb>
either way, "one person asked a question that generated discussion" isn't necessarily sufficient reason to do a bunch of work documenting something :-) (but it's fine if we want to do that)
21:31
<littledan>
it's better for history and research and whatnot.
Sounds like use cases of an archive?
21:32
<ljharb>
oh sure, fair
21:32
<ljharb>
then yeah that's the main reason i guess
21:34
<littledan>
Are there reasons in addition to archival why we should do this transfer?
Any other reasons? Anybody?
21:43
<Chris de Almeida>
Any other reasons? Anybody?
to be clear, you're asking for reasons why stage 0 proposal repos should be owned by the tc39 GH org, right?
22:05
<littledan>
Yes
23:48
<ljharb>
what are the reasons why they shouldn't be?
23:51
<Michael Ficarra>
if they haven't been presented to TC39, they're effectively unrelated to our work
23:52
<Michael Ficarra>
they shouldn't be given an air of legitimacy
23:52
<Michael Ficarra>
can any old rando online make a repo, write "TC39 sux" in the README, and ask us to move it into our org?
23:52
<Michael Ficarra>
I would hope not
23:53
<bakkot>
prior to being approved by the committee for stage 1, it's one person's proposal, not TC39's proposal
23:53
<Michael Ficarra>
also Ecma doesn't care about archival of stuff that basically only happened in someone's head
23:54
<Michael Ficarra>
they care about archival of materials related to our work