What does "&c" mean?

re: speakers identifying the points they want recorded in the notes

this is an undue burden on speakers, and in practice would rarely be emphasized

i don't see how more notes would ever be bad

bottom line is that pro steno is a big improvement over the status quo, and we have yet to hear about any better concrete solutions

apaprocki: Yes, this is what notes are for. Historically many people were against too many notes, now people are more in favor of more notes, and also we have "editor's notes" which can be removed/maybe collapsed. At this point it'd just be a lot of work to write the notes

that's fine, both viewpoints could be recorded and noted

my main pain point in the past was that there was no link between recorded spec text and the notes documents/meetings where they were discussed

I think we still never link from the spec to the notes, we just include some notes in the spec

yulia: I'm supportive to this, what I want is a really small doc, done in parallel with said transcription, with only highlights. By highlights I mean 3 bullet points + and other bullet points with resolution.

I would expect "delivering a promise" here to require wrapping it.

yulia: and to repeat myself: I don't think it's fair to ask anyone to capture those highlights if we are already doing a lot with the current notes we have today. The stenographer transcription would work great supporting this highlight document and any other summary people would eventually write.

So, to tie this together, it'd be great to get professional support for transcriptioning so that we can put the notes effort into this higher level work of creating summaries of rationales and linking them to the spec.

So, to tie this together, it'd be great to get professional support for transcriptioning so that we can put the notes effort into this higher level work of creating summaries of rationales and linking them to the spec.

is that irregexp

Yeah, that could be done. It would be easy to add collapsable notes. the hard part is to write all of them

fwiw I think the git log is good enough for this already that the additional work is not worth it

right, i'm asking if that's compliant

well isn't this change at a higher layer to the part where you hook into V8's implementation?

If you want to explore how the specification was written, you can also view the source with its history in searchfox [https://searchfox.org/ecma262/source/spec.html].

https://arai-a.github.io/ecma262-compare/

ryzokuken: bterlson Rob Palmer Could we add a 10-minute agenda item tomorrow to draw a conclusion on the stenography question?

of course it was arai !

But does this give you a blame of the spec?

if we wanted to do that , we would need to have a render of every change to the spec hosted somewhere

well, no, ecmarkup is JS and can run client-side

wait littledan you asked for funding this before asking the rest of the committee!?!?!?!?!?!? 🤯

we asked for human typesetters who lay out books for a living, not a software license

every time stuff like this comes up i feel like the apparent situation is that someone got 90% of the way there and then got stuck on bureaucracy :(

seems like the decision tree still maps?

wait, so is safari's output for String.prototype[Symbol.iterator].toString() compliant? (starts with function [Symbol.iterator]() {)

sure I guess I just wanted to be clear what amount of volunteering I was up for. writing automation: yes. an hour of work per year: yes. more than that: no. unclear if this would be enough

those people are so impressive

can elastigirl mute when others are speaking? we are getting feedback on the call

(but it also transfers the burden to the presenter, which is a bit of an impediment for an active presenter)

Looks like we have less complaints with active rob mixing

Yeah, this whole proposal seems like overkill; I'd kinda prefer that we just don't try to be generic in terms of permitting an argument which does not have [[SetData]] (but maybe we rejected that in the past?)

part of me also is wondering why we dont just require that the arg actually be a Set

I never felt that was the case, and thought that "private symbols" was supposed to be what you are talking about. I always looked at symbols as a means to emulate interface in static languages so as to avoid collisions due to the same name/different intent.

one is WAY MORE burdensome

sorry, I should have made the constraints here clearer:

• we want to accept things which are not actually Sets for reasons discussed at length in the previous meeting, most significantly that we consider the only good way to modify the behavior of a Set to use composition, rather than inheritance, which means Set-like things will come up in real life
• just invoking the string-named has directly runs into this problem with Map where doing that will work as if you'd passed the Set of the map's keys only if the map is larger than the set, which is extremely painful behavior for an API to have

interface Setish {
  hasKey(k): boolean;
  size: number;
  keys(): Iterator;
}

It's unfortunate you can't intersect with an array, which instead has length and includes, and whose keys are indices, but you have to draw the line somewhere I suppose.

This was why I suggested putting the whole protocol behind one symbol, so that serves as a single namespace for everything.

interface Setish {
  [Symbol.Setish](): {
    size: number:
    has(v): boolean;
    values(): Iterator;
  }
}

Set.prototype[Symbol.Setish] = function() { return this; }

again, making Array set-like makes intersection O(n^2), which seems bad

yeah but it means the protocol is a lot more complicated; for anything for which it was not just return this; it would be a lot more work overall