2025-05-01 [11:57:26.0768] I’m working on [#3581](https://github.com/tc39/ecma262/pull/3581) (Array.fromAsync). I’m figuring out the last two esmeta errors in [this job](https://github.com/tc39/ecma262/actions/runs/14781083646/job/41499977134?pr=3581). It looks like Array.from’s iteration machinery has changed a lot since I last checked. Now Array.from uses a new IteratorStepValue operation. There’s no analogous AsyncIteratorStepValue operation yet, is there? [12:03:49.0924] Correct [12:03:55.0128] Would it be worth for the Array.fromAsync pull request to define new AsyncIteratorStepValue, AsyncIteratorStep, and AsyncIteratorNext operations? [12:04:07.0239] No, probably not until there's more stuff which uses it [12:04:09.0220] * Would it be worth for the Array.fromAsync pull request to define new AsyncIteratorStepValue, AsyncIteratorStep, and AsyncIteratorNext operations, to match Array.from’s algorithm? [12:05:53.0805] You can use the underlying operations, though [12:06:32.0107] IteratorNext works fine on async iterators I think [12:06:57.0067] and then after awaiting the result you can use IteratorComplete and IteratorValue [12:08:23.0861] which I guess is pretty much what you're doing already, except manually calling .next instead of using IteratorNext, which is fine [12:08:47.0583] don't worry too much about esmeta errors; if they don't look like actual errors you can ignore them [12:09:24.0650] it isn't capable of handling everything in the spec and there's a file we can use to mark things as expected errors if we decide it's an esmeta bug [12:10:28.0991] in this specific case, yes, it looks like it's because of not recognizing the new IfAbruptCloseAsyncIterator macro, which makes sense; macros are hard to typecheck and we don't have any explicit marking for them [12:29:07.0148] Thank you very much for your great help. 2025-05-03 [10:22:42.0260] Is the content I added implicitly given somewhere? Or is it a mistake? (CompileAtom is not explicitly defined for production `Atom :: \ AtomEscape`, but is defined for `AtomEscape`) [10:27:00.0937] https://tc39.es/ecma262/#sec-algorithm-conventions-syntax-directed-operations > Unless explicitly specified otherwise, all chain productions have an implicit definition for every operation that might be applied to that production's left-hand side nonterminal. The implicit definition simply reapplies the same operation with the same parameters, if any, to the chain production's sole right-hand side nonterminal and then returns the result. 2025-05-04 [08:37:09.0833] Is this correct? For RegExp: `/[\p{Hex}]/u`: https://tc39.es/ecma262/#sec-compiletocharset For production ` UnicodePropertyValueExpression :: LoneUnicodePropertyNameOrValue`, `s` is `Hex`, in step 2 it calls `UnicodeMatchPropertyValue(General_Category, s)` UnicodeMatchPropertyValue (https://tc39.es/ecma262/#sec-runtime-semantics-unicodematchpropertyvalue-p-v) 2. Assert: v (in this case, `Hex`) is a property value or property value alias for the Unicode property p (in this case, General_Category) listed in PropertyValueAliases.txt. https://unicode.org/Public/UCD/latest/ucd/PropertyValueAliases.txt And in https://unicode.org/Public/UCD/latest/ucd/PropertyValueAliases.txt, there is no entry starts with `gc ; Hex` so this assert should fail. Did I miss something? Thanks! [08:37:58.0270] * Is this correct? For RegExp: `/[\p{Hex}]/u`: https://tc39.es/ecma262/#sec-compiletocharset For production ` UnicodePropertyValueExpression :: LoneUnicodePropertyNameOrValue`, `s` is `Hex`, in step 2 it calls `UnicodeMatchPropertyValue(General_Category, s)` `UnicodeMatchPropertyValue` (https://tc39.es/ecma262/#sec-runtime-semantics-unicodematchpropertyvalue-p-v) 2. Assert: `v` (in this case, `Hex`) is a property value or property value alias for the Unicode property `p` (in this case, General_Category) listed in PropertyValueAliases.txt. https://unicode.org/Public/UCD/latest/ucd/PropertyValueAliases.txt And in https://unicode.org/Public/UCD/latest/ucd/PropertyValueAliases.txt , there is no entry starts with `gc ; Hex` so this assert should fail. Did I miss something? Thanks! [09:06:13.0933] yeah that looks like a bug [09:06:52.0918] you should open an issue and cc `@mathiasbynens` [09:28:51.0800] https://github.com/tc39/ecma262/issues/3586 [09:59:18.0932] Doesn't that fail the early error? [10:00:21.0659] (The one that says it's a Syntax Error if that Assert would fail.) [10:01:27.0408] Or am I missing the crux of the example? [10:04:38.0803] `/[\p{Hex}]/u` is intended to be legal, I am pretty sure [10:04:42.0514] certainly it is treated as such [10:04:51.0935] * certainly it is treated as such in actual implementations [10:06:28.0618] oh, actually, that early error rule is okay, because "Hex" appears in Table 70. [10:06:42.0586] * oh, actually, that early error rule passes, because "Hex" appears in Table 70. [10:45:13.0214] PR to fix: https://github.com/tc39/ecma262/pull/3587 2025-05-05 [13:15:43.0660] With regards to the Stage 4 criterion “pull request has been sent to tc39/ecma262 or tc39/ecma402, as appropriate, with the integrated spec text”, is Stage 4 for Array.fromAsync blocked by [#2942](https://github.com/tc39/ecma262/pull/2942) merging into main because its pull request ([#3581](https://github.com/tc39/ecma262/pull/3581)) is based on #2942? This is assuming that the editors sign off on #3581, which is blocking both Stage 3 and Stage 4. [13:20:33.0703] No [13:20:53.0503] Or rather, to be precise, it is blocked from merging into main, but that's fine [13:21:41.0097] Excellent, thank you. It sounds like I can request Stage 4 for Array.fromAsync at this month’s plenary, assuming that #3581 gets editor sign-off. [13:22:44.0437] Yes, and also you should add it to the agenda when you're ready without first waiting for the editors; editors generally prioritize reviewing things which are on the agenda 2025-05-06 [21:23:44.0661] Is this an Annex B only test? https://github.com/tc39/test262/blob/93d63969bccbf8b4471b7c7fadc875099b7668d3/test/language/literals/regexp/S7.8.5_A1.4_T2.js#L4 It constructed a RegExp like this: `new RegExp('\\' + String.fromCodePoint(8204))` It parsed as IdentityEscape. In the main spec it is `[~UnicodeMode] SourceCharacter but not UnicodeIDContinue`, (btw 8204 is a UnicodeIDContinue), but in annex B it is ` [~NamedCaptureGroups] SourceCharacter but not c [+NamedCaptureGroups] SourceCharacter but not one of c or k ` [21:23:55.0723] * Is this an Annex B only test? https://github.com/tc39/test262/blob/93d63969bccbf8b4471b7c7fadc875099b7668d3/test/language/literals/regexp/S7.8.5_A1.4_T2.js#L4 It constructed a RegExp like this: `new RegExp('\\' + String.fromCodePoint(8204))` It parsed as IdentityEscape. In the main spec it is `[~UnicodeMode] SourceCharacter but not UnicodeIDContinue`, (btw 8204 is a UnicodeIDContinue), but in annex B it is ``` [~NamedCaptureGroups] SourceCharacter but not c [+NamedCaptureGroups] SourceCharacter but not one of c or k ```` [21:24:01.0073] * Is this an Annex B only test? https://github.com/tc39/test262/blob/93d63969bccbf8b4471b7c7fadc875099b7668d3/test/language/literals/regexp/S7.8.5_A1.4_T2.js#L4 It constructed a RegExp like this: `new RegExp('\\' + String.fromCodePoint(8204))` It parsed as IdentityEscape. In the main spec it is `[~UnicodeMode] SourceCharacter but not UnicodeIDContinue`, (btw 8204 is a UnicodeIDContinue), but in annex B it is ``` [~NamedCaptureGroups] SourceCharacter but not c [+NamedCaptureGroups] SourceCharacter but not one of c or k ```` [21:27:35.0494] (also for language/literals/regexp/S7.8.5_A2.4_T2.js) 2025-05-07 [02:02:30.0685] CharacterClassEscape[UnicodeMode] :: [+UnicodeMode] p{ UnicodePropertyValueExpression } [+UnicodeMode] P{ UnicodePropertyValueExpression } Is it missing a [+UnicodeSetsMode] version of those 2 production? otherwise I cannot find a way to parse `/^\p{Basic_Emoji}+$/v` [02:02:39.0627] * ``` CharacterClassEscape[UnicodeMode] :: [+UnicodeMode] p{ UnicodePropertyValueExpression } [+UnicodeMode] P{ UnicodePropertyValueExpression } ``` Is it missing a [+UnicodeSetsMode] version of those 2 production? otherwise I cannot find a way to parse `/^\p{Basic_Emoji}+$/v` [03:26:20.0323] In the spec, `+UnicodeSetsMode` only occurs in conjunction with `+UnicodeMode`. (i.e., roughly, `USM` implies `+UM`, or `+USM` is a subset of `+UM`), so any RHS guarded by `[+UM]` 'succeeds' for all cases of `+USM`. [03:26:51.0212] I think. [03:28:19.0938] * In the spec, `+UnicodeSetsMode` only occurs in conjunction with `+UnicodeMode`. (i.e., roughly, `+USM` implies `+UM`, or `+USM` is a subset of `+UM`), so any RHS guarded by `[+UM]` 'succeeds' for all cases of `+USM`. [04:08:18.0340] oh, I checked all Pattern, all Pattern[+USM] is also marked as [+UM] [04:29:13.0221] yup [10:25:47.0522] I want to proposal a method for finding the item in an iterable which has the largest value according to some function, for example "find the person with the largest age" or whatever. This comes up a lot IME, enough to be worth having in the standard library even though it's like a four or five lines to do with a loop or `.reduce`. There's two natural ways to do this: either take a function from input items to a number, or take a comparator. both work, first is often more convenient, second is strictly more general. Thoughts? We could in principle support both. (Even in the same function, just by switching on `callback.length === 1`, but... not that option). [10:25:50.0905] * I want to proposal a method for finding the item in an iterable which has the largest value according to some function, for example "find the person with the largest age" or whatever. This comes up a lot IME, enough to be worth having in the standard library even though it's like a four or five lines to do with a loop or `.reduce`. There's two natural ways to do this: either take a function from input items to a number, or take a comparator. both work, first is often more convenient, second is strictly more general. Thoughts? We could in principle support both. (Even in the same function, just by switching on `callback.length === 1`, but... not that option.) [10:28:13.0403] I suppose one way to solve the dilemma is to have a function which lifts a `T -> number` mapper to a `(T, T) -> { -1, 0, 1 }` comparator, and expect people to use that, as in `people.maxByComparator(Compare.by(person -> person.age))`. [10:28:23.0027] (java calls the latter operation `Comparator.comparing`) [10:31:18.0117] * I want to make a proposal for a method for finding the item in an iterable which has the largest value according to some function, for example "find the person with the largest age" or whatever. This comes up a lot IME, enough to be worth having in the standard library even though it's like a four or five lines to do with a loop or `.reduce`. There's two natural ways to do this: either take a function from input items to a number, or take a comparator. both work, first is often more convenient, second is strictly more general. Thoughts? We could in principle support both. (Even in the same function, just by switching on `callback.length === 1`, but... not that option.) [10:35:55.0695] Isn't this the same API design question we had with `uniqueBy`? You can either give a mapper or a comparator, and we probably just want both. [10:36:23.0108] wouldn't this be less efficient? [10:36:55.0073] Pretty similar, yeah, although the "comparator" for uniqueBy is not a comparator in the sense of "a function which can be passed to `.sort`", whereas it is here [10:37:43.0416] same big-O, but requires computing 2x as many calls of the `T -> number` function, yes [10:39:58.0017] I actually am kind of coming around to the idea of switching on the `.length` of the callback [11:07:59.0209] A comparator for unique has to compare against all previous unique values. O(N^2) A comparator for largest only has to compare against the current winner. O(N) [11:08:47.0338] This does sound useful. I currently reach for `.sort(c).at(-1)` when in a pinch [11:10:15.0541] Effectively, this would be sugar for something like this, yes? ``` people.reduce((acc, p) => p.age > acc.age ? p : acc) ``` [11:11:45.0081] * Effectively, this would be sugar for something like this, yes? ``` people.reduce((acc, person) => person.age > acc.age ? person : acc) ``` [11:17:47.0739] Isn't that good enough for this use case? [11:23:00.0146] I mean, isn't a for loop good enough for this use case? [11:23:17.0823] Reduce has the "empty list" exception which is annoying IMO [11:23:39.0017] for a winner like method I'd rather an empty set returns undefined as the winner [11:25:26.0155] `reduce` is basically the same kind of hammer as a for loop. Personally I like it when the language provides common, simple operations even when they're already achievable with the language's existing general purpose tools. [11:25:41.0578] ehhhhh no I was definitely planning on proposing this where it's an exception if you call it on an empty list [11:25:51.0317] https://es.discourse.group/t/array-prototype-winner/1015/ [11:26:10.0531] ("winner" is a terrible name) [11:27:05.0384] > <@bakkot:matrix.org> ehhhhh no I was definitely planning on proposing this where it's an exception if you call it on an empty list Only a weakly help opinion. I'd be curious what other languages do (the ones that can't return a fancy maybe type) [11:27:25.0224] > <@bakkot:matrix.org> ehhhhh no I was definitely planning on proposing this where it's an exception if you call it on an empty list * Only a weakly held opinion. I'd be curious what other languages do (the ones that can't return a fancy maybe type) [11:28:54.0922] Passing an initial value to reduce to avoid the throw is annoying because you can't easily pass `undefined` as that will get passed as an argument, so now need to handle that extra case on the comparator [11:29:06.0643] You can avoid this by passing a sentinel value as the second argument, e.g. `{ age: -Infinity }` in the example case. [11:29:32.0529] Sure, now do that with a complex type with more than one prop :) [11:31:06.0673] Returning undefined I can always `?? error()` to get back to the exception behavior. Going from exception to undefined is more work [11:32:11.0687] ``` people.reduce((acc, person) => person.age > acc?.age ?? -Infinity ? person : acc, null) ``` [11:32:47.0121] python's `max` has an optional `default` argument to use in case of empty list, and throws if the list is empty and no default is provided [11:32:51.0212] which seems pretty reasonable [11:33:27.0120] other languages return fancy maybe types [11:33:39.0244] https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#max-java.util.Comparator- [11:34:17.0291] https://docs.rs/itertools/latest/itertools/fn.max.html [11:34:30.0248] a default that is only used for empty sounds good, that isn't passed to the comparator [11:35:31.0253] god this language could've been so much better if we had a built-in Maybe in the early days [11:35:55.0174] Or allowed any breaking changes ever. [11:35:56.0104] And monoid protocols [13:05:43.0103] > <@aclaymore:matrix.org> Only a weakly help opinion. I'd be curious what other languages do (the ones that can't return a fancy maybe type) So Rust has both `max` and `max_by` methods on iterators where the later takes a comparator function and the former only works with values that implement “Order”, so mainly numbers etc In Rust’s case they return an Option type then None if the list is empty, so `undefined` in the js equivalent. https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.max_by [13:06:23.0545] > <@aclaymore:matrix.org> Only a weakly help opinion. I'd be curious what other languages do (the ones that can't return a fancy maybe type) * So Rust has both `max` and `max_by` methods on iterators where the later takes a comparator function and the former only works with values that implement “Order”, so mainly numbers etc In Rust’s case they return an Option type then None if the list is empty, so `undefined` in the js equivalent. https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.max_by That being said, option is a fancy return type, so doesn’t help here. But I do like the max and max_by names better. [13:06:51.0543] > <@aclaymore:matrix.org> Only a weakly help opinion. I'd be curious what other languages do (the ones that can't return a fancy maybe type) * So Rust has both `max` and `max_by` methods on iterators where the later takes a comparator function and the former only works with values that implement “Order”, so mainly numbers etc In Rust’s case they return an Option type then None if the list is empty, so `undefined` in the js equivalent. https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.max_by That being said, Option is a fancy return type, so doesn’t help here. But I do like the max and max_by names better. [13:09:40.0892] Maybe empty vs unaryarrays are the true JS option type, as you can't `null.map`. I tried that in a codebase once when I was in my wild youth phase [13:09:52.0007] * Maybe empty vs unary arrays are the true JS option type, as you can't `null.map`. I tried that in a codebase once when I was in my wild youth phase  [13:23:59.0270] `max` and `max_by` are the right names but rust has them exactly backwards :( [13:24:35.0119] `sort` takes a comparator, `sortBy` would take a `T -> number` [13:24:39.0775] ditto max and maxBy [13:24:55.0682] * ditto `max` and `maxBy` [13:25:10.0054] I guess the `T -> number` one is called `max_by_key` [13:25:39.0362] * I guess the `T -> number` one is called `max_by_key` in rust [13:26:09.0163] but yeah I think the natural naming is `max` taking an optional comparator and `maxBy` taking a mandatory `T -> number` [15:41:38.0096] This is it, yes. Both variants are needed, and this is the right naming/assignment. [15:46:36.0516] @bakkot:matrix.org throwing or returning a special value for empty iterators? [16:02:01.0696] Michael Ficarra throwing but with an optional second `default` argument to return in that case, like python does [16:03:06.0568] though I guess that's annoying in the specific case that you want to use the default comparator but provide a default [16:03:10.0822] oh well I guess [16:03:18.0628] yeah I think that's what I would do as well [16:03:33.0694] still not 100% convinced it's needed, but if we do have it, that's how I would do it [16:06:49.0157] I definitely want `unique`/`uniqueBy` more [16:07:58.0061] I forget: given that we have no array prototype methods, how would those work? on iterator.prototype but returning array? [16:08:41.0037] I guess they could return an iterator, ok [16:09:08.0618] just kind of weird to have an iterator that uses O(all previous items) memory [16:31:24.0875] yeah that was the feedback I got at the last presentation [16:31:38.0806] it's weird but I don't think it's *surprising* if you consider for even a second what it's doing [16:32:50.0440] and I don't think that's fatal to the proposal 2025-05-11 [04:40:47.0817] bakkot if we have max on iterators, we should also have min and minmax [06:20:40.0941] I think TabAtkins suggested the idea of having a general comparator inverter [07:24:08.0718] min yes, minmax no [14:15:43.0164] why not minmax? [14:38:31.0012] just doesn't come up enough to be worth it IME 2025-05-12 [18:59:00.0084] `std::minmax` seems common enough in C++, though I haven’t had time to dig into specific reasons why people have been using it: https://github.com/search?q=std%3A%3Aminmax+language%3AC%2B%2B+&type=code [18:59:41.0818] * `std::minmax` seems common enough in C++, though I haven’t had time to dig into specific reasons why people have been using it: https://github.com/search?q=std%3A%3Aminmax+language%3AC%2B%2B+&type=code https://sourcegraph.com/search?q=context:global+std::minmax&patternType=keyword&sm=0 [20:33:51.0979] two orders of magnitude less results than `std::max` though 2025-05-13 [00:24:38.0120] Aapo Alasuutari Regarding https://github.com/Igalia/webengineshackfest/issues/48, I suggest getting in touch with TC53 if you haven't yet (even though that's not about a subset of JS, if you are working on embedded devices it's very relevant) [14:00:47.0889] > <@nicolo-ribaudo:matrix.org> Aapo Alasuutari Regarding https://github.com/Igalia/webengineshackfest/issues/48, I suggest getting in touch with TC53 if you haven't yet (even though that's not about a subset of JS, if you are working on embedded devices it's very relevant) Hoo, interesting. I was not aware of this. 2025-05-15 [20:14:41.0288] I guess ES does not really have any "ASCII whitespace tests"? Anyway, people might find the fact that the web platform has multiple definitions of ASCII whitespace interesting. https://github.com/whatwg/infra/issues/670 plus, previously, https://github.com/whatwg/infra/pull/649 [20:42:39.0237] there's https://tc39.es/ecma262/#sec-white-space / https://tc39.es/ecma262/#prod-WhiteSpace [20:47:06.0746] Yeah, not ASCII-restricted though [21:31:57.0678] i would assume that anything that `/\s/` matches is considered whitespace. any other definition would be very surprising [21:47:39.0840] well, the behavior of `\s` is based on General Category "Space_Separator" plus select additions and _not_ on property White_Space—as a result, U+0085 NEXT LINE (which has property White_Space) is not matched by it (regardless of flags), while U+FEFF ZERO WIDTH NO-BREAK SPACE (which does not have property White_Space) _is_ matched by it. See also https://github.com/tc39/ecma262/pull/3303 , which was unfortunately closed [21:54:31.0389] i'm just saying that "\s" literally means "whitespace", so regardless of specs or standards or web reality, it'll be surprising if that doesn't hold [21:54:44.0809] unicode nonsense doesn't change that either way :-) [21:54:49.0843] ASCII whitespace is a useful thing to have in specs when attempting to parse data formats, etc. JSON has its own definition (which does not match JS's `\s` or `White_Space`). [21:55:33.0979] sure, JSON is its own unique thing. we changed JS a number of years ago to include 2 more newline characters so it'd match JSON, as i recall [21:56:03.0594] i think that regardless of what the current reality is, we should be striving to make there be a single definition of "whitespace", and for all things to match it [21:57:10.0504] in particular, at least, i hope nobody would ever add an *additional* definition of "whitespace" :-) [21:57:11.0793] I don't agree; I think it's useful for there to be separate definitions for whitespace and ASCII whitespace. [21:57:29.0792] This is similar to how both lowercasing and ASCII lowercasing are useful operations, for example. [21:57:37.0272] if the latter is a subset of the former, it might be fine, sure [21:58:12.0925] i'm saying the ideal is one definition; more than one is fine, but we should be striving to minimize that. if we end up with two that's pretty decent. [22:00:45.0610] the base64 proposal is the first place to my knowledge that introduces "ASCII whitespace" to JS https://tc39.es/proposal-arraybuffer-base64/spec/#sec-skipasciiwhitespace [22:01:02.0822] it does not include vertical tab [22:01:49.0619] it does include form feed [22:02:46.0625] this matches the infra definition, which is probably where I copied it from [22:07:17.0111] ah, yes, because that's what btoa uses https://infra.spec.whatwg.org/#forgiving-base64-decode [22:08:20.0509] including excluding vertical tab https://github.com/tc39/proposal-arraybuffer-base64/issues/5#issuecomment-1783929861 2025-05-17 [21:18:04.0387] what ever happened to comprehensions? [21:18:22.0784] everything else in Brendan's slide here made it in [21:30:38.0887] the story i heard was, dherman wrote on the whiteboard, side by side, nested comprehensions and nested for loops [21:30:48.0006] everyone was so viscerally disgusted by the comprehensions the feature was dropped [21:31:11.0042] which seems fine to me [21:41:33.0883] having tried to understand a few python programs with nested comprehensions, i don't disagree [21:52:06.0374] ... incomprehensions [09:09:47.0920] If you nest a comprehension, Python actually calls your work and gets you fired. [09:11:18.0151] chained comprehensions (`[y for x in xs for y in x.ys]`) is on thin ice 2025-05-18 [07:28:49.0907] i hear guido himself writes you unsolicited feedback regardless of what company you're at 2025-05-19 [23:54:28.0060] "this is so not zen" [01:03:43.0871] The version I heard was that the comparison was between comprehensions and arrow functions, and people felt comprehensions didn't really add much once you had arrow functions and map/filter/etc. [01:04:24.0916] I think it was https://github.com/dherman/sudoku [01:40:01.0070] that would make sense [01:40:11.0953] Python picked a weird horse in that race [06:02:28.0782] Given the limited power of lambdas in Python, I think they made the right one for them [07:27:57.0880] ah I'd always viewed it as "they made lambdas intentionally cumbersome such that comprehensions would become 'the one obvious way to do it'" [07:28:16.0490] not sure if that's a post-hoc rationalization though [07:28:53.0860] * ah I'd always viewed it as "they made lambdas intentionally cumbersome such that comprehensions would be 'the one obvious way to do it'" [07:29:35.0441] I think Python lambdas long predate comprehensions. [07:32:44.0358] I think either not existing must be prior to Python's popularity but I don't see a justification for making lambdas deliberately hard to use otherwise [07:32:54.0307] lambdas were 1.0, comprehensions were 2.0 [07:33:03.0142] Whenever I write Python I tend to avoid lambdas and comprehensions, though I won't rewrite them away after some copypasta. Certainly aspects of the language I like less. (Though the 2 to 3 switch I still dislike the most of all things Python ever did.) [09:16:03.0578] Hey all... trying to decide if a new proposal is worthwhile... Node.js recently received a request to add APIs to the `Buffer` interface that would allow a `Buffer` to maintain an internal position for relative writes.. for instance, the following code: ``` const buf = Buffer.alloc(10); let pos = 0; buf.writeInt8(1, pos++); buf.writeInt8(2, pos++); // .. ``` would become ``` const buf = Buffer.alloc(10); buf.writeInt8(1); buf.writeInt8(2); // .. ``` Or something similar, with the `pos` identifying the offset being held by an internal slot. There is, however, a preference within Node.js to avoid adding further to the `Buffer` API and we would instead prefer to see a mechanism added to the standard `DataView` for this purpose. The proposal would be to add a new `[[WriteOffset]]` internal slot and variations on the `setXXXXX` and `getXXXX` APIs that make use of it... for instance: ``` const dv = new DataView(new ArrayBuffer(10)); dv.writeInt8(1); dv.writeInt8(2); // ... ``` [09:16:34.0913] This idea is that by building this into `DataView`, user code could avoid potentially buggy bookkeeping around the position [09:16:54.0280] But it's certainly not clear if there's enough motivation to formulate a full proposal [09:30:24.0249] i don't think it would be a good idea to add statefulness anywhere, personally [09:30:32.0880] the `pos++` code seems pretty simple as it is [09:32:43.0845] it becomes a bit awkward and error prone when writing multiple values of different sizes but I share the concern about the statefulness. [09:34:49.0408] fwiw, here's the relevant issue in Node.js https://github.com/nodejs/node/issues/58348 [10:17:03.0943] I was just gonna say "this sounds like they were inspired by Java's ByteBuffer", then I open the issue and that's exactly what they said [10:23:11.0708] I'd say they should use DataView and if they're concerned about the bookkeeping being messy, they should separate their business logic from the code that's responsible for serialisation to a bytestring so they're not interleaved [10:28:46.0317] This seems like it'd be awkward to fit onto the DataView API; either you'd have new APIs that move the cursor, or have some mode that makes the cursor move when the existing write APIs are called... At index 0? No, I guess new APIs are the only choice. [10:30:07.0012] 8 bytes more memory on DataView isn't too horrible, it's a rare object after all, but I guess the non-interaction between the cursor and the existing APIs would be somewhat weird. [10:36:19.0320] That seems similar to how RegExp has .lastIndex, do we consider it something good or a mistake? [10:39:02.0716] I definitely consider it a mistake [10:39:22.0832] but a wrapper class which took a regexp and also kept an index would be fine [10:40:08.0553] similarly, I don't think DataView should have an offset, but I would be fine with having a different class which kept an offset [10:41:09.0758] we shouldn't retrofit DataView [10:41:17.0761] > Claude, please write me a wrapper for DataView in JS which keeps an internal offset which is updated when calling read/write methods, like Java's ByteBuffer. Also add a method for reading/writing TypedArrays (writing should use a wrapper TypedArray, with appropriate offsets, so that you can `.set` the entire argument instead of needing to write individual values). https://gist.github.com/bakkot/6726adcf9ed361790d1063b41dbf4148 [10:41:30.0512] this seems perfectly fine to be done in userland? [10:41:39.0979] not sure why it warrants a built-in [10:41:43.0641] that said I don't think this is worth adding to the language; the current state of things is fine and it's not hard to do [10:43:12.0319] not even done in userland, actually, Node can ship a thing if it thinks it's useful [10:43:28.0013] (unless it also doesn't want to do so unilaterally anymore due to other server runtimes. not sure what the situation is) [11:21:31.0858] DataViewWithCursor is certainly useful and I’ve written one at least twice, for whichever methods the format demanded, most notably Zip. Same taste as bakkot for read/write methods, plus `seek` to rhyme with files. Agree with shu it’s not particularly important for it to be in the language. Not particularly important that it be omitted. There’s an async analogue (`File`) if it’s backed by I/O. [11:26:52.0503] > <@shuyuguo:matrix.org> (unless it also doesn't want to do so unilaterally anymore due to other server runtimes. not sure what the situation is) The preference is to avoid new node specific apis when they likely overlap with standard options. We have been slowly trying to deemphasize use of Buffer, for instance [11:27:34.0703] This could also be a web platform API consideration [11:27:52.0166] That is, we could ask whatwg to consider a standard API here [11:29:03.0068] it also doesn't feel like a web api [11:30:12.0129] Ok, I'll take this as a sign that a proposal is unlikely to advance ;-) ... appreciate the feedback all [11:30:29.0849] yeah, my read on the feedback for "overlap with standard options" you're getting in this room is "unlikely to overlap, because people don't think it's worth adding to the language" 2025-05-20 [22:51:23.0771] Maybe a new wrapper type specifically for writing, which holds the cursor data internally? The ArrayBuffer family of things already makes use of wrapper types, so it seems natural to me. 🤔 2025-05-21 [19:20:54.0201] I made this slide for a talk, explaining our process in a simplified way. Sharing in case somebody else would find it useful. [11:31:44.0280] neat! [11:56:06.0564] Could whoever manages the esdiscuss instance lock , and possibly ban the user? [12:00:38.0612] have we not put that in our CoC yet? [12:00:45.0368] we definitely talked about it at length at one point [12:01:55.0882] who discussed it, the CoC group? [12:02:51.0119] off the top of my head, i can see translation as an acceptable use case, but i'm not sure if it's really possible to tell [12:03:02.0251] https://matrixlogs.bakkot.com/TC39_Delegates/2024-02-26#L18 [12:03:06.0937] we've certainly had people, when called out on using an LLM, say they were doing so because they weren't confident in their command of english [12:03:46.0566] i personally think those past cases, that reason was an excuse, but hard to tell [12:04:21.0575] I think there was more offline discussion about it at a plenary as well [12:04:48.0618] anyway, it would be nice if the CoC committee would make it explicit for us [12:04:57.0753] i see where kevin's coming from with "i'll feed it through a translator myself", need to think on that [12:05:25.0919] i've never had a productive technical discussion like that though, where people go back and forth posting in their preferred language [12:06:43.0685] I have but not often [12:06:56.0879] nicolo made a good point on another occasion though that this severely negatively affects search [12:07:01.0855] https://matrixlogs.bakkot.com/TC39_Delegates/2025-03-04#L3 [12:07:30.0597] so I am ok with people using LLMs for translation [12:08:04.0357] but that is not the same as "using an LLM because they aren't confident in their english" - the most common example of the latter thing is that you write a short summary in your language and then ask ChatGPT to _write a whole post_ in English [12:08:09.0099] rather than just doing a translation of what you wrote [12:08:24.0424] and this is a thing I want to discourage [12:08:26.0095] the rocket ship emojis are just annoying, not actually wasting my time... unlike the *content*. translation is fine, but authorship has to be human. [12:09:57.0993] otoh, there are models that are trained specifically for translation, and they don't make you sound like a spam email [12:10:12.0620] chatgpt doesn't make you sound like a spam email if you just ask for translation [12:10:17.0563] why does chatgpt use emojis in the nerdiest old-person way so often, anyway? [12:10:18.0078] it's perfectly fine at that task [12:10:56.0540] my previous manager used emojis exactly like that [12:11:24.0756] were they >50? [12:11:42.0514] definitely not [12:11:56.0560] huh, interesting [12:12:22.0180] I've personally noticed an "emoji divide" with how people of different ages employ them [12:14:38.0433] describe what the "nerdy old person way" is for this nerdy middle-aged person please? [12:17:21.0101] emojis used as punctuation / illustration / tone-markers on sentences which required none of those [12:17:22.0679] kinda like bullet points or summaries of a line or just in places where they don't make sense [12:17:48.0261] wow those explanations were scarily similar [12:18:00.0488] 🧢 https://youtu.be/EUJJiYycsnw?t=75 [12:20:07.0705] 🤠 = lying?? that's a new one for me [12:20:29.0655] oh no it was "pretending to be happy" [12:20:34.0714] baseball cap is lying [12:21:05.0092] 🧢 I guess [13:05:48.0439] no cap [13:45:35.0907] i thuoght it was a young person thing to use emojis as punctuation [13:45:52.0204] that's an old person thing? how can that be an old person thing? emojis weren't around when we learned the online communication style [13:48:02.0900] the old person window shifts by about a year every year. it no longer means wwii vet. it means me. [13:48:25.0632] and also some people significantly younger than me [13:48:36.0278] seems to me "the nerdiest old-person way" to use emojis is not at all [13:49:09.0203] this also wrapped around. there’s a generation that only uses emojis ironically when mocking old people [13:49:52.0956] And now there's another generation younger than them that doesn't care either way [13:49:58.0412] i assume you have all read https://en.wikipedia.org/wiki/Because_Internet [13:51:31.0428] i only use emojis when i post to linkedin [13:52:22.0312] i also like 🥺 and use that regardless of the content [13:53:01.0434] 🫣😅 [13:53:19.0418] i don't know what that means [13:54:38.0900] These are the two I use a lot and unironically [13:54:49.0051] Seemed to fit [13:55:03.0007] what is the connotation of 🫣? [13:57:13.0669] Both are indicating that I should be slightly embarrassed by what I've just written but I did it anyway. There's a difference between them I'm struggling to verbalize 😅 [13:57:33.0062] oh interesting. i would not have guessed that for the first one [13:58:12.0419] i thought the first one was something like "i'm afraid to confront the thing being said because it's such a car wreck" or something [13:59:32.0375] https://github.com/tc39/code-of-conduct/issues/62 [13:59:44.0024] Please add thoughts, comments, suggestions, etc. here [14:05:02.0524] As a non-native speaker - I did ask LLMs to explain fragments of conversation to me but would not trust them to make my arguments for me. On the other hand, I have an anecdote from way before LLMs on how very bad computer aided communication is still valuable from back when I worked at a company doing pre-statistical rule based translation https://github.com/naugtur/naugtur.github.com/blob/master/generator/contents/articles/what-if-were-overestimating-ai-again/index.md#language-is-a-human-thing [14:36:37.0130] i don't think it's a CoC issue, nor does it need to be [16:56:40.0416] How exactly does the tc39-transfer/tc39 split work? I'm trying to do something similar (move someone else's personal repo into an org that I'm an admin for). [16:57:03.0789] You used to be able to add collaborators as admins of personal repos, but they removed that ability at some point fairly recently. :( 2025-05-22 [17:02:27.0654] I am very confused by this [17:03:01.0446] what is the CoC if not the thing which sets the rules for what behavior is reasonable in our interactions with each other [17:31:33.0132] I can't speak for Jordan, but I would offer that the use of tools/methods does not directly violate the CoC tenets [17:41:57.0661] the issue is perhaps not so much that an LLM was used -- it was that low-quality, unreviewed nonsense was sent for consideration and ended up wasting peoples' time -- which is not respectful, and arguably, a violation of the CoC. but it's not that it was inherently the use of an LLM that was a violation, but how it was used [17:44:50.0707] I don't really care whether they reviewed the output or not, and whether it's "low quality" isn't something random contributors can effectively judge - I assume that they would not have posted it if they thought it was low quality [17:45:04.0241] the problem is that I do not care to spend my time reading or responding to LLM outputs [17:45:31.0089] (not including "outputs" which are just translation or whatever) [17:45:37.0436] so to me the problem is in fact use of the tool to author comments [17:46:05.0623] and to the extent that this is not currently captured by the CoC, I know, and that's why I am proposing to update the CoC [17:51:02.0579] what I am trying to say is that it's not necessarily always to be considered misuse. if someone uses an LLM to help them write something, and they believe it's accurate and useful, it's difficult for me to interpret that as a violation of the code of conduct. I agree with you on not wanting to read "LLM outputs", but it's tricky to totally define what that is, and to nail down what a prohibitive clause would look like [17:51:23.0841] that said, unless something has changed, you are proposing only that a disclaimer be attached to such comments, stating that an LLM was used to help generate it, in part, or in whole. is that accurate? [17:56:34.0899] My current proposal is: > Author your own comments > Any contributions or comments must be your own writing, not the product of LLMs or other tools. Do not prompt an LLM to expand on or explain your idea and then post the output; just provide the idea itself. > Machine translation is permissible, including translation by an LLM, but your use of translation should not introduce any new content. [17:57:04.0661] I would also be ok with saying that you must disclose any use of LLMs, but I'd just immediately ignore anything where they said they used the LLM to write the post, so I think this is better [17:57:17.0666] I agree we don't want to forbid "use of LLMs" in general [18:04:01.0440] I think I agree. the proposed text could use a little wordsmithing but LGTM. still, I have doubts of whether that is most suited for CoC vs contributing guide / how-we-work [18:23:01.0591] this seems like a pretty central case of what the CoC is for, to me? [18:23:12.0639] it's defining what kinds of conduct are acceptable in any TC39 space [18:23:20.0712] that's what the CoC is for [20:00:12.0691] the CoC is not the place for banning tools; it's for establishing expectations for interpersonal conduct [20:08:30.0002] This seems like an expectation for interpersonal conduct to me [20:14:48.0719] The goal isn't to ban any particular tool - I don't want to read the output of Markov chains either [20:15:14.0744] The goal is to establish the expectation that the comments you post were written by you, not by some other system [20:17:36.0397] I agree the CoC is for defining acceptable conduct. it seems we disagree on what a conduct issue is. I suggest that the use of a tool, like an LLM, on its own, does not equate to behavior the CoC is meant to guide our behavior towards each other, rather than to prescribe how we may or may not write [20:19:02.0085] How we write to each other is part of how we behave towards each other [20:19:14.0329] I completely agree [20:19:27.0947] Anyway, I won't be at this meeting but I can put something on the agenda for the following one, I guess? I didn't think this would be controversial [20:21:13.0713] Needs to go through plenary anyway I suppose [20:21:18.0817] I don't know that it's controversial. I think we all have the same goal and are generally in agreement. it's the particulars about where such guidance or rules live, is where we may not agree [20:23:35.0798] your proposed text above was excellent. maybe a little massaging is all I'd ask. but after that, we seem to run into difficulty adding it to the CoC vs elsewhere [20:25:52.0146] Happy to take some wordsmithing now also, wherever it ends up [22:10:09.0138] is the issue perhaps that this, like spam, is something that wouldn't warrant _reporting_ to the CoC committee? [22:11:02.0514] (but I'm rather surprised to see Jordan and Tab, say, differ on this interpretation) [22:11:10.0428] either way I like the proposed text [22:12:17.0659] * (but I'm rather surprised to see Jordan and Tab, say, in disagreement on this) [23:45:01.0461] i mean, if it doesn't warrant reporting, it doesn't belong in the CoC [23:45:22.0821] and spam isn't a CoC issue either, it's just that CoC moderation teams tend to be the ones who combat spam, because they have the permissions and vigilance to do it [23:46:10.0930] as far as i'm aware you have never been able to do that - certainly not for at least a decade. the only repos that can go into tc39-transfer are ones from people in the tc39-transfer org, ie, delegates/IEs [08:44:21.0106] More generally, would we see plagiarism as a violation of the code of conduct? The APA definition is "the act of presenting the words, ideas, or images of another as your own", and that seems to be what we're trying to prevent here, in the narrow case of presenting LLM generated text as your own work. [08:44:26.0689] I'm wondering if it would be less controversial to add text about plagiarism to the CoC. [08:45:34.0264] Many people do not regard use of LLMs as plagiarism, so I wouldn't want to use that word. [08:46:44.0355] I could tweak my proposal to also list "or any other source", maybe? As in: Author your own comments Any contributions or comments must be your own writing, not the product of LLMs or other tools **nor any other source** [emphasis added]. Do not prompt an LLM to expand on or explain your idea and then post the output; just provide the idea itself. Machine translation is permissible, including translation by an LLM, but your use of translation should not introduce any new content. [09:03:40.0622] > <@ljharb:matrix.org> as far as i'm aware you have never been able to do that - certainly not for at least a decade. the only repos that can go into tc39-transfer are ones from people in the tc39-transfer org, ie, delegates/IEs Ah, kk, so I can make an org, add this person as a member, have them transfer their repo in, then I can transfer the repo onwards to another org I'm an admin for? [09:54:56.0560] that works, but it's easier for them just to bounce it to you directly [09:54:59.0678] * that works, but it's easier for them just to bounce it to you directly as the first step [16:34:05.0695] Oh, can you just directly transfer a repo between people? That would work, yeah. 2025-05-28 [07:25:55.0815] Does anyone else have difficulty applying suggestions in reviews on tc39/ecma262 pull requests? If I click the “Commit suggestion” button, GitHub gives this error: “This diff has recently been updated. Refresh and try again.” [07:26:55.0927] yeah it's a known github bug for as long as I can remember [07:27:19.0717] something to do with when the person leaving the suggestion has commit rights to the target repo or something, it's really strange [07:32:49.0451] I thought it was a misleading message that was actually caused by the large file size and would not manifest against e.g. README.md/CONTRIBUTING.md/etc. [07:34:14.0231] i guess it's possible that they fixed the original bug but it still manifests with the same error message for large documents [07:34:24.0394] That free ad space in the embedded preview due to the accidental URL…