01:09 | <Chris de Almeida> | in case we forget to mention it tomorrow, please do not ever use the I'm done speaking button in TCQ. thank you! |
01:50 | <rkirsling> | TC39 rule: never stop speaking |
01:53 | <Jesse (TC39 ๐บ๐ธ)> | can we remove the button? |
02:07 | <Chris de Almeida> | https://github.com/bterlson/tcq/pull/68 |
06:57 | <bakkot> | whatever happened to the rewrite? |
10:02 | <eemeli> | Looks like Christian Ulbrich and Tom Kopp were working on it here at least up until last June: https://github.com/zalari/tcq/pull/7 |
16:11 | <Rob Palmer> | Sign in form with video link will be posted around 9am PT. |
17:09 | <keith_miller> | Is there an ETA for the video link? I still don't see one in the reflector. |
17:20 | <Rob Palmer> | Not quite. Michael is still setting up AV. |
17:20 | <keith_miller> | Oh I forgot these start at 10 not 9 lol |
17:21 | <Rob Palmer> | correct - there is 38 minutes until go time |
17:46 | <Rob Palmer> | The video link will be posted on the Reflector very soon |
17:51 | <Rob Palmer> | The video link is now posted via the Sign-in form on the Reflector! |
18:03 | <ljharb> | maybe we should add an actual persistent temperature check to tcq (like, physical room temperature) |
18:05 | <canadahonk> | fwiw its PST (-8) not PDT (-7) |
18:13 | <Aki> | SUMMARIES ARE GOOD |
18:13 | <Aki> | YAY SUMMARIES |
18:24 | <Rob Palmer> | If anyone would like to be the TC39 Liaison to IETF please let the Chairs know or reach out to Samina directly. |
18:26 | <ryzokuken> | we already keep track of the W3C i18n WG for TG2 |
18:27 | <ryzokuken> | and some WGs from Unicode for that matter |
18:27 | <eemeli> | Only technically, mind. I've a recurring conflict with their call, and Ben has not been able to attend many of their meetings. |
18:29 | <Chris de Almeida> | please share resources for where folks should go to get involved in TC55 (matrix room, meeting info, etc) |
18:29 | <canadahonk> | https://wintertc.org + https://github.com/wintercg/admin |
18:31 | <Andreu Botella> | matrix room: #wintertc:matrix.org |
18:32 | <Aki> | rock and roll |
18:32 | <nicolo-ribaudo> | Thanks a lot Aki again for all the help with making sure that our technical work follows what Ecma needs |
18:33 | <canadahonk> | thank you all ECMA folks ๐ |
18:36 | <kriskowal> | Youโre audible, Aki |
18:36 | <Chris de Almeida> | oh reminder, there should not be notes during this period |
18:37 | <Chris de Almeida> | so please remove them and tell the transcriptionist to pause |
18:37 | <Ashley Claymore> | it has been paused |
18:37 | <nicolo-ribaudo> | Don't worry, we do things right also with you out of the call! |
18:37 | <Chris de Almeida> | and don't discuss here ๐ |
18:38 | <Chris de Almeida> | of this, I have no doubt ๐ |
18:38 | <nicolo-ribaudo> | You can come back |
18:41 | <ljharb> | can we make sure the transcription bot, and transcription human, have resumed? |
18:41 | <nicolo-ribaudo> | The human is back and apparently the bot was not running in the first place |
18:42 | <Aki> | Now that Google Docs has "export as markdown", is it time to update the agenda item template? |
18:45 | <Chris de Almeida> | say more |
18:47 | <Aki> | Allows us to use the standard document styles and get markdown as a result https://snaps.akiro.se/2502_ji3bx.png |
18:49 | <ljharb> | the only reason the notes items are they way they are, afaik, is for ease of markdown conversion, so it seems fine to change them? |
18:50 | <Chris de Almeida> | suggest validating the quality of the export first |
18:52 | <Ashley Claymore> | Maybe we could try on Thursday, when the agenda is light. To reduce 'risk' if the formatting needs manual fix up |
18:53 | <Aki> | I've used the export for notes for other committees |
18:53 | <Aki> | I'm very happy with it |
18:58 | <bakkot> | nicolo-ribaudo: re: linking other web specs, I bet we could figure out how to automatically generate ecmarkup-compatible biblios from web specs if we really want to |
18:58 | <bakkot> | the ecmarkup biblios are very simple |
18:58 | <shu> | gotta snipe tab into supporting it in bikeshed |
18:58 | <nicolo-ribaudo> | Right now we just need to link to URL and fetch so doing it manually is probably less effort than making it work automatically, but if we'll need to link to more stuff I'll look into it |
18:59 | <nicolo-ribaudo> | Currently we also rely on Infra, but as part of the rewrite we are just going to rely on ECMA-262 built-ins instead |
19:11 | <Ashley Claymore> | One thing we sometimes do is wrap parts of the transcription in backticks, e.g. when someone references Object.is .Do you know if these would carry-through, or would we need to do this by changing the font? |
19:12 | <Aki> | it escapes them, but that's a very easy search & replace |
19:12 | <Aki> | y'all have no idea how many regex search & replaces I do on every meeting's notes |
19:13 | <bakkot> | have you considered just asking an LLM to "make it good" :D |
19:13 | <Aki> | ๐คฎ |
19:13 | <ljharb> | can't wait to find out what lovecraftian horrors end up being stage 4 due to that |
19:17 | <Michael Ficarra> | somehow I feel much more comfortable trusting the speech-to-text than I do a text transform, and I can't explain why |
19:18 | <nicolo-ribaudo> | Probably speach-to-text worst case writes nonsense, rather than plausible-looking wrong stuff |
19:18 | <bakkot> | the trick with text transforms is to have it generate a diff, which you can then easily review for correctness |
19:19 | <bakkot> | also no, modern speech-to-text definitely writes plausible-looking wrong stuff a lot |
19:19 | <Aki> | Eggma showed up a lot in the last TC55 meeting |
19:20 | <nicolo-ribaudo> | https://docs.google.com/presentation/d/1LjsJhdTIP3wgo1odtVa-qbfyGU5M1W9YMm0AtKnJJKk/edit#slide=id.p |
19:20 | <bakkot> | https://github.com/bakkot/transcribe-to-gdocs/blob/fb863c5a314d078f2a0c60d26cf8774f08dd068a/replacements.js#L35-L46 |
19:20 | <Michael Ficarra> | eggma is a new one lol |
19:21 | <bakkot> | (though this list was when using google's old speech-to-text; whisper is much better and I hear gemini is better still although I have not yet gotten around to hooking it up) |
19:24 | <Aki> | eggman |
19:25 | <Michael Ficarra> | if Whisper wasn't already better than a human transcriptionist (it probably is), Gemini certainly is |
19:26 | <ljharb> | coo coo ca choo |
19:27 | <rbuckton> | Oh, I missed this in my constraints. I need to be present for the Decorators discussion, so if it can remain after the lunch break I would appreciate it. I will add this to the agenda as a late breaking constraint |
19:29 | <Michael Ficarra> | except for 100%, right? |
19:37 | <canadahonk> | ๐ค as someone who has tried/done "professional" transcriptions a while ago, I think Whisper is good at speech-to-text but has terrible/no formatting last I looked |
19:39 | <bakkot> | 50% of the human transcriptionists we've hired have actively harmful formatting (double spaces between sentences, linebreaks every few words, etc), so "no formatting" is still superior |
19:41 | <canadahonk> | yeah agree with that |
19:46 | <Ashley Claymore> | Not sure if still true today, but in the past the human transcriptionists seem to handle people talking over each other better. Giving each their own >> lines |
19:47 | <littledan> | Could someone record a conclusion on the chair election in the notes? |
19:48 | <littledan> | (I'm happy to share the doc link in a DM if anyone needs) |
19:49 | <canadahonk> | |
19:51 | <nicolo-ribaudo> | Nope, this is it: Speaker's Summary of Key Points
Conclusion
|
19:51 | <littledan> | please edit the notes and add a summary and conclusion section, saying who was elected. It is currently missing. |
19:51 | <littledan> | I mean, I just pasted that in |
19:51 | <littledan> | I'm not sure if someone people believe that the earlier text implies the summary/conclusion |
19:51 | <littledan> | but... I just can't make sense of it |
19:51 | <canadahonk> | oh I read conclusion as conclusion of opinion oops nvm |
19:51 | <littledan> | we just don't have a list in the notes of who was elected |
19:52 | <canadahonk> | i'll do in break if no one else does |
19:52 | <littledan> | (this is normal -- almost nobody writes their own summary and conclusion without prompting, but I didn't know who to prompt for this topic) |
19:53 | <nicolo-ribaudo> | Done |
19:57 | <Chris de Almeida> | presenters! please note, the topics in the overhead bins have shifted during flight: https://hackmd.io/dp19kCC5QBeG1W37oESrfQ?view |
21:20 | <nicolo-ribaudo> |
|
21:21 | <nicolo-ribaudo> | What is the burden with shipping first? Is it that you are the one that's going to find compatibility bugs? |
21:22 | <eemeli> | littledan: Did you really mean Stage 3, or should that have been 2.7? |
21:23 | <ljharb> | 3 is when it's time to implement and ship, so while ideally things would be blocked at 2.7 if there's no desire to implement, 3 would be fine too |
21:23 | <ljharb> | but it's definitely subpar to have something be stage 3 that nobody's prioritizing |
21:23 | <bakkot> | re the isSafeNumeric item later, Number toString technically allows implementations a choice of outputs in some cases https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-numeric-types-number-tostring |
21:23 | <bakkot> | does anyone actually... do that |
21:25 | <James M Snell> | I will say that it's rather frustrating as someone tracking the decorators spec work for some time... what I heard is that implementers don't want to prioritize it because they don't want to be the first to ship, but that they don't want to be the first to ship because the work is not prioritized..... what I'm not hearing at all is do the implementers just not want to implement decorators at all? Is this just a delay tactic to ultimately kill the proposal? |
21:29 | <rbuckton> | For many syntax features, developers are often comfortable with using a build tool to transform new syntax under the expectation that that transformation step can be removed once evergreen browsers have been updated to support the feature, but that requires those browsers to continue to make progress on shipping those features. Many syntax transformations are fairly cheap, though that's not always the case. Async functions and generators required fairly significant transformations and helper libraries to support, which adds overhead to bundles. The transformed emit for stage 3 decorators can also be quite large, which has a negative impact on bundle size and initial load time. |
21:30 | <rbuckton> | Even if feature availability is lopsided across browsers, developers can use server-side UA sniffing (or even client side with import() ) to ship a leaner bundle with native decorators on browsers that support them, and a transformed bundle on browsers that don't. |
21:31 | <bakkot> | possible in principle and I wish people did it more, but in practice I have ~never seen server-side UA sniffing for serving scripts with downleveled features to browsers which don't support something |
21:32 | <ljharb> | i think facebook might do it, but i've never actually seen it |
21:32 | <rbuckton> | possible in principle and I wish people did it more, but in practice I have ~never seen server-side UA sniffing for serving scripts with downleveled features to browsers which don't support something |
21:33 | <Michael Ficarra> | possible in principle and I wish people did it more, but in practice I have ~never seen server-side UA sniffing for serving scripts with downleveled features to browsers which don't support something |
21:33 | <snek> | one of the npm-to-web cdns does it, idr the name |
21:33 | <bakkot> | origin trials are most often APIs which you can just make conditional within a script instead of UA sniffing |
21:34 | <bakkot> | we do a lot of weird things! but that's a one-off for a particular feature we needed, not a general mechanism for arbitrary features |
21:36 | <bakkot> | polyfill.io did for APIs but that's a slightly different thing than syntax |
21:37 | <bakkot> | I don't think many places are using npm-to-web CDNs in prod |
21:37 | <bakkot> | well, presumably lots of hobbyist stuff |
21:37 | <rbuckton> | possible in principle and I wish people did it more, but in practice I have ~never seen server-side UA sniffing for serving scripts with downleveled features to browsers which don't support something |
21:38 | <bakkot> | I agree some people do it; we do it. But it's very very rare in my experience, looking at random retailers and hotels and so on. |
21:42 | <nicolo-ribaudo> | syg: What we are doing with import defer, is that deferred namespace objects guarantee that they will never have a .then property. This doesn't actually change the promises machinery, but makes sure that deferred namesapces are inert to it. And we can do it because they are already very exotic objects |
21:42 | <rbuckton> | If decorator downlevel emit size is a significant concern, it might be worth that kind of temporary split to produce a leaner bundle when possible. Web performance optimization is a major area of focus for large scale applications. |
21:43 | <shu> | thanks. still says to me there's a datapoint that we consider "then" a special evil worth special casing |
21:46 | <littledan> | We did already make Object.prototype be exotic (to have a frozen proto) but I agree that exotic with respect to then is an extra form of weirdness |
21:49 | <bakkot> | Mathieu Hofman: for the Promise.resolve constructor lookup, see https://github.com/tc39/proposal-faster-promise-adoption/issues/1 |
21:49 | <littledan> | For the notes: every time someone says "object dot proto", they mean Object.prototype , right? Not Object.__proto__ |
21:50 | <bakkot> | currently the check is IsPromise(p) && p.constructor === C ; I think it should be IsPromise(p) && GetPrototypeOf(p) === C.prototype |
21:50 | <bakkot> | GetPrototypeOf usually triggers user code, but can't trigger user code once you pass the IsPromise test |
21:53 | <Mathieu Hofman> | Yes this is when the "SafePromiseResolve" issue came up last time |
21:54 | <nicolo-ribaudo> | Are firefox use counters public, with a list of example websites, like Chrome's? |
21:55 | <Mathieu Hofman> | I basically want to make this check into a "SafePromiseResolve" that fast path promises that do not re-enter, and delay by one tick the ones that may. Then anyone can use that operation, possibly even await . |
21:55 | <Mathieu Hofman> | That's not sufficient if someone overrides %PromisePrototype% then and constructor properties |
21:56 | <bakkot> | isn't it? |
21:56 | <bakkot> | Promise.resolve does not do a lookup of .then on things which pass that check |
21:56 | <Mathieu Hofman> | It does for constructor if I recall. |
21:56 | <bakkot> | Right, it does IsPromise(p) && p.constructor === Promise |
21:57 | <bakkot> | but if we make it IsPromise(p) && GetPrototypeOf(p) === C.prototype then it would not do anything user-observable (on real promises) |
21:57 | <bakkot> | and I bet we can get away with that |
21:57 | <bakkot> | this also applies to await since it uses the same machinery |
21:58 | <bakkot> | and await also does not do an actual .then lookup at all, it just does a PromiseResolve and then uses the built-in PerformPromiseThen |
21:58 | <Mathieu Hofman> | defineProperty(Promise.prototype, 'constructor', {get() {} }) |
21:58 | <bakkot> | I don't know what that's intended to be a response to |
21:59 | <bakkot> | I am proposing to change the machinery so nothing ever looks at .constructor |
21:59 | <snek> | what constitutes a brand check |
21:59 | <snek> | like what granularity |
21:59 | <snek> | there are so many ways to organize objects |
21:59 | <nicolo-ribaudo> | A sync side-effect-free way to tell wether an object has a particular internal slot or not, for any slot |
21:59 | <Mathieu Hofman> | Oh, if you think that's web compatible |
22:00 | <snek> | for every internal slot? |
22:00 | <bakkot> | I give it reasonable odds |
22:00 | <bakkot> | since the only thing that happens if something starts failing the check is that they get another microtask tick |
22:00 | <nicolo-ribaudo> | Well, a brand check is for one internal slot, and Jordan would like every internal slot to have a brand check |
22:00 | <snek> | yeah i mean my question is what the consensus applied to |
22:01 | <snek> | because there are a lot of internal slots, how does one decide which ones are relevant in this case |
22:01 | <sffc> | Frank is ill, and I will now be presenting his slides on Intl Locale Info. Rob Palmer Chris de Almeida ryzokuken |
22:01 | <Mathieu Hofman> | Yeah I just need to think through the different cases of "subclassing" that the constructor check is meant to handle. |
22:02 | <ryzokuken> | hope he recovers soon, thanks for the heads up |
22:02 | <ljharb> | every internal slot that has observably different behavior, i suppose |
22:02 | <Mathieu Hofman> | Anyway, I'd be happy with anything that allows anyone (spec or user code) to stop triggering sync code during Promise.resolve |
22:02 | <ljharb> | and luca's comment seems somewhat related, in that it relates to the overarching committee goal throughout ES6 of making DOM objects JS-implementable |
22:03 | <bakkot> | I am very firmly convinced that the goal of making host things 100% doable in userland was a mistake |
22:03 | <bakkot> | that gave us Symbol.concatSpreadable and etc |
22:04 | <bakkot> | mostly doable in userland is good but I think it's probably OK if you can't polyfill this particular behavior? |
22:04 | <ljharb> | i'm not personally invested in implementable in userland, fwiw |
22:04 | <bakkot> | like, people probably aren't going to start relying on being able to stick .then on your polyfilled webIDL thing |
22:04 | <ljharb> | are there no webIDL thenables? |
22:04 | <bakkot> | don't think so |
22:04 | <ljharb> | because being able to implement one of those seems important for engines implemented in JS, if so |
22:04 | <James M Snell> | if it's not doable in JS then there are a ton of web platform APIs that node.js, deno, etc would have a difficult time implementing this for |
22:05 | <snek> | though engines implemented in js have their own object graph, so its kind of a moot point |
22:05 | <bakkot> | I think for node etc you could just have a built-in thing to mark objects as special in this way, and then mark them? |
22:05 | <bakkot> | as long as V8 exposes this as a bit you can set on an arbitrary object |
22:05 | <James M Snell> | Such built-in things become rather expensive from a perf cost |
22:06 | <bakkot> | hm, ok |
22:06 | <James M Snell> | anything that requires calling down into C++ becomes rather expensive in aggregate |
22:06 | <bakkot> | it could take a list of objects and just do a single call, if the concern is the number of times you cross the language barrier |
22:06 | <ljharb> | ones 100% implemented in JS yes, but not in eg node where they use JS to augment (and sometimes polyfill) standard features not implemented in JS |
22:07 | <shu> | do you need to mark objects often? |
22:07 | <Andreu Botella> | anything that requires calling down into C++ becomes rather expensive in aggregate |
22:07 | <shu> | is it like, per instance? |
22:07 | <shu> | ...why... would we do this? |
22:07 | <canadahonk> | fyi chairs I'm good to present math.clamp from now for scheduling |
22:08 | <James M Snell> | well, it's not just node.js itself. Also thinking about user-land provided polyfills of standardized apis |
22:09 | <James M Snell> | at the very least, it seems we have consensus that there's a problem to address here. I think there's likely multiple ways to address it but I want to make sure we do not prematurely take JS polyfillability off the table |
22:10 | <canadahonk> | is it fine to do the login form twice or if not could someone dm the meeting link? |
22:10 | <bakkot> | how important do you think it is to be able to polyfill this specific weird behavior? because it feels not that important to me |
22:10 | <ljharb> | yes, it's fine to do it multiple times |
22:10 | <ljharb> | i mean hermes still needs to polyfill Promise.resolve for react native, using JS, so they'd need it |
22:11 | <James M Snell> | having experienced this issue before with a userland polyfilled implementation, I'd personally say it's important |
22:12 | <snek> | technically this does exist, there's a kitchen sink object called the "extras binding" |
22:12 | <James M Snell> | oh god, please don't expose this to users |
22:12 | <shu> | snek: for me it's like, can you, with a straight face, say a thing is intended to be a thenable? if not, it'd be nice if we disallowed it to be a thenable at a language level |
22:12 | <Chengzhong Wu> | it triggers an emotion to see "how important to be spec compliant" in a tc39 channel |
22:13 | <bakkot> | well like I don't think people should be trying to polyfill document.all |
22:13 | <bakkot> | the language has a lot of weird corners |
22:13 | <snek> | well with a straight face i would say that modules aren't intended to be thenable. but idk how many people agree with me on this (well if anything, based on my original proposal being rejected, i know people don't agree with me) |
22:13 | <ljharb> | (+1 that subclassing builtins was a mistake) |
22:14 | <bakkot> | I definitely agree but that ship has sailed |
22:14 | <bakkot> | we can't now make them not-thenable |
22:14 | <Ashley Claymore> | .constructor.name.match(/promise|defer/i) |
22:14 | <bakkot> | but we did for deferred namespace objects at least |
22:15 | <ljharb> | i'd love it if we used null proto more aggressively for new spec-created objects; it seems like it'd avoid a whole class of problems |
22:15 | <snek> | time to merge the extends null spec pr? |
22:16 | <rbuckton> | FYI on terminology, a "thenable" is any object with a then method, regardless as to whether it is a promise or matches the Promise/A+ specification. i.e., if typeof x.then === "function" it's a "thenable". Being a "thenable" doesn't make it Promise-like. |
22:16 | <snek> | i'm aware |
22:16 | <bakkot> | I want this but weren't there still unresolved questions? |
22:17 | <littledan> | yeah, the PR didn't work at all |
22:18 | <snek> | the pr /works/, people just don't agree on the behavior |
22:19 | <rbuckton> | I only mention it because I've been running afoul of developers making the wrong assumption, or assuming the meaning of "thenable" has changed over the years. I'm mostly making the point so it's on the record in the chat log. |
22:19 | <snek> | like we have a set of test cases (which you can read in the pr), which delegates don't agree on the output of, or at least didn't last time it was brought up |
22:21 | <ljharb> | as i recall (disclaimer: i haven't read the PR in years), the options atm are either:
(and i think also either option, but "only statically") and i think each option had a number of folks whom received an "ick" from it |
22:23 | <nicolo-ribaudo> | Wow reading through that PR I really dislike what some comments are proposing |
22:23 | <eemeli> | We're skipping the break? |
22:24 | <ryzokuken> | the break is delayed |
22:24 | <ryzokuken> | we'll break for 30 at the end of this presentation |
22:24 | <nicolo-ribaudo> | Charis can you update the agenda item on tcq? |
22:24 | <ryzokuken> | done, thanks |
22:24 | <bakkot> | https://github.com/tc39/ecma262/pull/1321 is the class extends null PR |
22:24 | <bakkot> | in case anyone else wants to have opinions |
22:24 | <bakkot> | or clean it up and bring it back :D |
22:25 | <snek> | i'm happy to bring it back if people agree on something |
22:25 | <Rob Palmer> | (Personal opinion) Just going back to the Decorators browser stalemate of "willing-to-ship-but-not-be-first", it makes me worry a tiny bit about the quality of signal Stage 3 is sending to non-browsers. If it gets unblocked, there's no worry. If it remains blocked or gets demoted, we will have unfortunately transferred risk to TypeScript that has followed our process and shipped the proposal - which has been a major churn for users of the older version of TS Stage 1 Decorators. |
22:25 | <snek> | can't solve a paradox |
22:25 | <Rob Palmer> | Maybe we could report on developer usage experience from Decorators TS to help inform/motivate browsers to begin shipping. |
22:26 | <snek> | well until they are open about why they're not shipping it, its kind of unclear what report they need, if any |
22:28 | <littledan> | This feature does not need to be a speedup to be useful, IMO. (Good to avoid false claims here though) |
22:29 | <bakkot> | I can't believe css shipped clamp in a different order than every other language |
22:29 | <bakkot> | that is such a bizarre developer-hostile decision |
22:30 | <snek> | i didn't know people put min after max |
22:30 | <bakkot> | is TabAtkins here, can we complain to them |
22:30 | <littledan> | CSS should have meeting minutes where they discussed this at some point... |
22:31 | <bakkot> | apparently a fairly common complaint https://github.com/w3c/csswg-drafts/issues/11427 |
22:35 | <nicolo-ribaudo> | The minutes are at https://github.com/w3c/csswg-drafts/issues/2519#issuecomment-387803089. It seems like it was for alignment with a CSS function that ended up not actually existing (minmax with 3 arguments) |
22:35 | <bakkot> | uuuuuuuuuuuugh |
22:36 | <Michael Ficarra> | nice |
22:36 | <TabAtkins> | What up |
22:36 | <bakkot> | css clamp has the wrong argument order, it is different from every other language, this probably means we can't have Math.clamp |
22:37 | <nicolo-ribaudo> | The question would be "does JS align with CSS, or with all the other non-web languages" |
22:37 | <snek> | the prior art used in this is painful |
22:37 | <TabAtkins> | As the issue says, there's both precedents |
22:37 | <shu> | i thought dbaron had adopted gen z slang but i see that fr is a unit :( |
22:38 | <nicolo-ribaudo> | new Math.Clamper(min, max).clamp(value) |
22:39 | <TabAtkins> | With hindsight, I agree the weight of precedent goes with val first |
22:39 | <ljharb> | fr fr |
22:39 | <ryzokuken> | (new (new Math.ClamperFactory(min))(max)).clamp(val) |
22:40 | <snek> | NumberConstrainmentBuilder |
22:40 | <ryzokuken> | problem solved |
22:40 | <ljharb> | don't forget the MathFactory |
22:40 | <kriskowal> | BigMath |
22:40 | <bakkot> | please take shitposting to tdz |
22:41 | <littledan> | I just don't think it's so useful to overthink this kind of thing (re sffc's comment) |
22:42 | <littledan> | hindsight? you just shipped this just now! |
22:42 | <littledan> | (anyway we've been there before) |
22:42 | <TabAtkins> | We resolved on it six years ago |
22:42 | <bakkot> | clamp is pretty old at this point https://developer.mozilla.org/en-US/docs/Web/CSS/clamp |
22:43 | <bakkot> | unfortunately... |
22:43 | <TabAtkins> | Anyway do the obvious thing in JS |
22:43 | <TabAtkins> | Css round() looks nothing like Math.round either |
22:44 | <bakkot> | fair point! |
22:44 | <TabAtkins> | Really it's only on the simplest of cases (single argument, or all arguments semantically identical) that we match |
22:45 | <ljharb> | eemeli: only the ones that start with "to" :-p this one wouldn't |
22:45 | <eemeli> | It would still be a very radical change. |
22:45 | <TabAtkins> | Css even fixed JS's dumb mistake with mod() (but still shipped the bad behavior as rem()) |
22:46 | <bakkot> | if we end up shipping rem with the other behavior that would be very funny |
22:46 | <ljharb> | i'm not sure it'd be "radical" - does anybody have the expectation that "all methods on a thing always return the same kind of thing"? |
22:46 | <TabAtkins> | I mean JS doesn't name either of them |
22:46 | <TabAtkins> | So that would be a self own |
22:47 | <ljharb> | i'd expect people call one method, and don't know or care about the ones they aren't calling |
22:47 | <TabAtkins> | And I *did* do significant name research to settle on mod/rem as the name pair |
22:49 | <bakkot> | someone used to push regularly for us to add those |
22:49 | <bakkot> | ... possibly Brendan actually? |
22:50 | <TabAtkins> | We still should! |
22:51 | <snek> | System.clamp |
22:51 | <ljharb> | sffc: being aligned on the motivation is for stage 1. are you objecting to that? |
22:51 | <eemeli> | Given that we already have Math.min and Math.max , I don't see how anything other than Math.clamp would be better. |
22:51 | <ljharb> | the main reason i see is that it'd also allow BigInt.prototype.clamp (and i guess that it resolves the argument ordering question) |
22:52 | <TabAtkins> | Yeah please do Math.clamp(v, min, max), y'all |
22:52 | <ljharb> | what would the bigint clamp be then? |
22:52 | <bakkot> | BigInt.clamp |
22:52 | <nicolo-ribaudo> | The reason I like a proposal for this is that there is a 50% chance to forget "when doing max(min(...), ...), I need to pass the min to max and the max to min". A built-in function for this is motivated if it makes it easier to pass the right number in the right place |
22:52 | <ljharb> | then y no Number.clamp ? |
22:52 | <bakkot> | because Math is the namespace for the number stuff |
22:53 | <TabAtkins> | Oh, I'm not in the meeting at I didn't see the context. But yeah sure, BigInt.clamp() |
22:53 | <snek> | Math.clamp(number|bigint) pls |
22:53 | <TabAtkins> | And yeah, Math has precedent |
22:53 | <eemeli> | I think the question about clamping bigints needs to be answered simlutaneously with min() and max() for bigints. |
22:53 | <bakkot> | those also go on BigInt |
22:53 | <TabAtkins> | Or the "three bigint arguments" on Math. +1 to @eemeli:mozilla.org: |
22:54 | <ljharb> | and in a world where we also have decimal, suddenly all the Math stuff "should" really be on Number, and Math is just weird legacy baggage? |
22:54 | <bakkot> | I think Number will always be privileged relative to any other numeric types |
22:54 | <snek> | are bigints not math |
22:54 | <bakkot> | so it is ok that it gets two namespaces |
22:54 | <littledan> | BigInts are not math |
22:54 | <bakkot> | re: Math.max(bigint) , https://github.com/tc39/proposal-bigint-math/issues/23#issuecomment-1275893064 |
22:54 | <bakkot> | I think this is very compelling |
22:54 | <ljharb> | ah, but 3n + 4n works |
22:55 | <bakkot> |
|
22:55 | <snek> | 1 + Math.max(...list) is -Infinity, is that more helpful in practice (not that it isn't the correct thing to return) |
22:56 | <bakkot> | it's not necessarily more helpful but it is what your code is already designed for |
22:56 | <bakkot> | and unexpectedly getting a TypeError is pretty weird |
22:56 | <bakkot> | also, separately, I don't like the return types of functions to depend on the types of their inputs |
22:57 | <nicolo-ribaudo> | I did not mention it because throw-away objects are probably bad, but Math.clamp(value, { min, max }) would also be a reasonable option |
22:57 | <snek> | but i think at a very high level if we want to continue to separate things out, prototype methods is a probably my preferred solution. cuz then (a, b) => a.min(b) works for any numeric types |
22:58 | <TabAtkins> | I did not mention it because throw-away objects are probably bad, but |
22:59 | <snek> | this makes me wish again that js had named arguments, separate from option bags |
22:59 | <TabAtkins> | Allows you to optionally clamp either side without having to either branch your function name or supply infinity |
22:59 | <rbuckton> | Math.BigInt.{ min, max, clamp, ...} is always an option. It's a bit odd to have Number -related methods on Math but BigInt related methods on BigInt . |
23:00 | <eemeli> | Have we actually considered named arguments and dismissed them at some point? |
23:00 | <TabAtkins> | Yes, sorta |
23:00 | <TabAtkins> | It's fallen on syntax grounds |
23:01 | <rbuckton> | In the same vein, Math.Decimal.{ min, max, clamp, ... } ... |
23:08 | <TabAtkins> | Specifically, the two obvious syntaxes are foo(arg1: v) and foo(arg1=v) , and both are problematic. |
23:09 | <Richard Gibson> | moar punctuation: foo(arg1:: v) |
23:09 | <rbuckton> | I thought it had fallen on "we already have { arg1: v } " grounds |
23:10 | <rbuckton> | foo(arg1=v) definitely is, but why is foo(arg1: v) problematic? Something like foo(arg1:= v) would work too |
23:11 | <rbuckton> | Though in some languages, := means "bind and initialize" |
23:11 | <TabAtkins> | while I was typing it i couldn't recall what was bad about arg:val , actually |
23:11 | <TabAtkins> | i suspect it is just that object bags take the air out of the room |
23:13 | <rbuckton> | Except that they're extremely inefficient. |
23:13 | <TabAtkins> | oh yeah they're bad, i agree |
23:13 | <TabAtkins> | maybe arg:val was just becuas eof its nearness to the trinary operator being potentially confusing |
23:14 | <rbuckton> | C# has both foo(arg1: x) and ?: , it's not especially confusing, IMO. |
23:15 | <Richard Gibson> | URL fragment directives use :~: ; we can't do worse than that |
23:15 | <rbuckton> | Especially since arg binding can only happen at the start of an argument. |
23:16 | <rbuckton> | Named arguments was an issue that partial application ran up against. Partial application only wants to bind Argument positions, and foo(x, { y: ? }) is not a valid Argument position, while foo(x, y: ?) would be. |
23:18 | <Ashley Claymore> | a little similar with parameter decorators, they don't work in the same vein for object-bag-as-named-argument-pattern |
23:20 | <eemeli> | I would find named arguments like foo(arg: value) to correspond rather well with the way we can already use foo({ arg: value }) . |
23:21 | <TabAtkins> | yeah, it probably is the most natural syntax for js |
23:24 | <rbuckton> | I think the biggest issue with named arguments is that parameter names aren't preserved in the face of .bind and method replacement via decorators. |
23:25 | <TabAtkins> | i mean, they could be. it's unobservable right now. |
23:25 | <TabAtkins> | (source visibility doesn't contradict this) |
23:25 | <rbuckton> | .bind could. Decorators could not, not without additional reflection over the method being decorated and some way to dynamically define named arguments. |
23:27 | <TabAtkins> | tho Python gets by without having either of those preserve names, because it has *args and **kwargs |
23:27 | <bakkot> | named parameters working automatically (without opt-in from the callee) would break all minifiers which would be kind of a shame |
23:27 | <TabAtkins> | so a decorator can just take and pass (*args, **kwargs) and preserve the arg name beahvior |
23:28 | <littledan> | I want to repeat my request to the meeting organizers that we enable recording and publishing as a pattern for any presentation |
23:28 | <bakkot> | arguments.named |
23:28 | <littledan> | it is a very good practice, for transparency and inclusion |
23:28 | <littledan> | thank you Mark for bringing it in here |
23:29 | <bakkot> | fwiw I strongly dislike having any public recordings of my voice (though there is at least one now) |
23:29 | <bakkot> | but would feel somewhat awkward about personally opting out of recording my presentations every single time |
23:29 | <rbuckton> | for example:
|
23:29 | <bakkot> | I guess we could have some practice of automatically overdubbing but that would be a lot more process |
23:29 | <kriskowal> | opt-in to record sgtm |
23:30 | <kriskowal> | opt-out to not-record sbtm |
23:30 | <rbuckton> | So yeah, named arguments would need to be passed along somehow. |
23:31 | <ljharb> | fwiw i am concerned about ephemeral spirited in-group discussion, or attempted whimsy spoken aloud, becoming like a conference talk that people can critique forever even as cultural standards shift. opt-in-only covers that tho. |
23:32 | <bakkot> | I don't think anyone was proposing recording the discussion, just the presentations |
23:32 | <littledan> | yes, this would be opt-in. (but generally I think the things which look bad in retrospect were already bad at the time.) |
23:33 | <kriskowal> | otoh, apologizing to forty people is tractable in a way that apologizing to everyone is not |
23:35 | <eemeli> | Yeah, that does make it sound like it'd break the web. |
23:35 | <bakkot> | well, not as we usually use the term |
23:36 | <bakkot> | but it would be pretty annoying for developers and also probably make all websites some amount larger eventually once the minifiers updated to preserve parameter names |
23:36 | <snek> | there are a lot of identifiers they have to preserve anyway |
23:37 | <Michael Ficarra> | there are? |
23:37 | <Michael Ficarra> | just eval |
23:37 | <Michael Ficarra> | what else? |
23:37 | <bakkot> | property names |
23:37 | <bakkot> | and options bag names |
23:37 | <Michael Ficarra> | those aren't identifiers, get out of here |
23:38 | <snek> | ๐คจ https://gc.gy/20c632fb-3230-4795-babd-ed57b11c0b22.png |
23:38 | <bakkot> | IdentifierName is, to be fair, technically not Identifier |
23:39 | <rbuckton> | imports from packages not bundled, exports exposed to end users, globals |
23:53 | <littledan> | FWIW I wouldn't mind normative text, requiring that hosts respect the immutability of immutability array buffers (but the assert reading makes sense too) |
23:58 | <bakkot> | I would probably do something like
|
23:58 | <waldemar> | If an assert failure makes the spec normatively incorrect, then an assert cannot be informative. Informative text cannot make a spec inconsistent. |
23:59 | <bakkot> | Why not? |
23:59 | <littledan> | but, it's text that implies no normative requirements on implementations |