| 09:07 | <Bakkot> | btw the note taking bot has some autocorrects thanks to michaelficarra now |
| 09:07 | <Bakkot> | feel free to suggest more to me and I'll try to sneak them in during pauses in talking |
| 09:08 | <Bakkot> | I just added a few including "Jason -> JSON" |
| 09:11 | <rricard> | nice, I thought it learnt |
| 09:11 | <Bakkot> | there are actually other models which let you give it a list of vocab words, which is really cool |
| 09:11 | <Bakkot> | unfortunately they don't work as well for this sort of audio |
| 09:12 | <robpalme> | training it on the entire set of tc39 notes might help |
| 09:13 | <Bakkot> | not a feature they offer, alas |
| 09:13 | <ljharb> | … and that was the fateful day EcmaNet became self-aware, and began inserting semicolons into code worldwide |
| 09:14 | <Bakkot> | whoever is selecting large blocks of the notes, could you not do that? |
| 09:20 | <rricard> | someone did that with the whole text yesterday regularly |
| 09:20 | <rricard> | here agaun |
| 09:20 | <rricard> | anonymous moose |
| 09:21 | <michaelficarra> | now that the bot is getting tuned and we're getting better at live editing the notes, this meeting's notes are FANTASTIC IMO |
| 09:24 | <Bakkot> | it is fascinating to me that the bot wants to spell "JSON" as "Json" |
| 09:24 | <Bakkot> | I will maybe add an autocorrect for that |
| 09:25 | <rricard> | anonymous moose again |
| 09:25 | <michaelficarra> | someone is still highlighting large blocks of text… |
| 09:25 | <rricard> | should I point of order? |
| 09:27 | <ljharb> | ystartsev: "JSON.module" seems like a strange way to me to add the ability to unfreeze+copy a frozen object, especially the first non-syntactic way to import a module |
| 09:27 | <ljharb> | would JSON.module be sync or async? would it work in Scripts as well as in Modules? |
| 09:27 | <ystartsev> | i would imagine it being similar to `import` -- we haven't delved deep on what this should look like or strong opinions here |
| 09:28 | <ystartsev> | the idea is that this would allow people who are expecting json.parse like behavior would be able to get it this way |
| 09:29 | <ljharb> | that would mean there's no way to "synchronously" import a normal, idiomatic, mutable parsed JSON object? |
| 09:30 | <ystartsev> | there are of course, other options, but that would break from what we currently have with `import` |
| 09:30 | <ljharb> | right |
| 09:30 | <ystartsev> | does that mean that its impossible? no, but thats a trade off we have to decide on |
| 09:30 | <ystartsev> | from my perspective, there is a use case, and an expectation, from users to have this behave something like json.parse |
| 09:30 | <ljharb> | right, which is "mutable" |
| 09:31 | <ystartsev> | yes |
| 09:31 | <ljharb> | also, imo a VERY strong expectation that it works like `require(json)` does in node |
| 09:31 | <ljharb> | which is also mutable |
| 09:31 | <ystartsev> | but, this could be error prone, since its also a copy |
| 09:31 | <ystartsev> | but that isn't possible with modules |
| 09:31 | <ljharb> | in node, it's not a copy, the require cache is a singleton |
| 09:31 | <ystartsev> | that is why we ended up leaning towards immutibility |
| 09:31 | <ljharb> | in node, for a decade, every required json file has been shared and mutable as a singleton, and in practice it hasn't caused issues |
| 09:31 | <ystartsev> | but its "leaning" its not "it must be this way or else" |
| 09:32 | <rricard> | for the sake of note takers repeating questions is useful |
| 09:32 | <ystartsev> | maybe i wasn't clear that we are not enforcing an opinion here |
| 09:33 | <ljharb> | i understood that :-) just exploring the suggestion/leaning |
| 09:33 | <akirose> | rricard: i agree |
| 09:33 | <robpalme> | ljharb: it may not have caused problems, but I can tell you it's a missed opportunity. it's costing us a MB of overhead because the emoji json data needs to be loaded once per app. for our host environment, we will soon switch that to be frozen and shared to save memory. |
| 09:34 | <michaelficarra> | I like this argument from gibson042 of mutability still being a big win since more people can transition from eval hazards |
| 09:35 | <ljharb> | robpalme: i'm a bit confused by that; how would it being frozen allow it to be shared per app? |
| 09:35 | <robpalme> | we run multiple users app inside what node would consider to be one app. today we must duplicate the structures because JSON imports are mutable. |
| 09:35 | <ljharb> | robpalme: ok, but you could choose to freeze them and then share them, no? |
| 09:36 | <robpalme> | yes! |
| 09:37 | <ljharb> | so how is "mutable by default" getting in the way of that option? |
| 09:37 | <robpalme> | because if apps become dependent on that assumption, we can't give them immutable values |
| 09:38 | <robpalme> | and 99.9% of usage is not dependent on it being mutable. people use it as read-only data loading. |
| 09:38 | <ljharb> | why would they become dependent on that assumption if your initial json modules implementation in your in-house platform chose to freeze them, regardless of what the standard says? |
| 09:38 | <ystartsev> | so, i don't really consider json.parse and require(json) to be really similar. one is a copy and the other is not. the hazard for developers is very different |
| 09:38 | <ystartsev> | i don't think that because the hazard exists that it means we shouldd replicate that behavior |
| 09:39 | <ljharb> | it's very fair that `JSON.parse` makes a copy every time |
| 09:39 | <ystartsev> | also, clarification -- exists in node. for those working on web apps they may only have the intuition from json.parse |
| 09:39 | <Bakkot> | i wonder if anyone optimizes `JSON.parse(JSON.stringify(x))` |
| 09:40 | <ystartsev> | you know, its sad but i have seen that code |
| 09:40 | <ljharb> | re selecting text, i wonder if someone's trying to paste the content in translation software to translate it to their language? |
| 09:40 | <ljharb> | (cc akirose ^) |
| 09:40 | <ystartsev> | possibly... |
| 09:41 | <rricard> | that would make sense |
| 09:41 | <rricard> | should we have a live translation bot |
| 09:41 | <ljharb> | also, did we ever figure out how to make the google doc show people's names when they're logged in? |
| 09:41 | <michaelficarra> | I thought it was axolotl? I don't want to wrongly blame moose |
| 09:41 | <ljharb> | i see it as chipmunk rn |
| 09:41 | <rricard> | I think we get diffferent animals |
| 09:42 | <michaelficarra> | oohhh lol well then that's not helpful |
| 09:42 | <rricard> | thanks yulia! |
| 09:42 | <michaelficarra> | that's a great idea, ystartsev |
| 09:42 | <ljharb> | queue needs advancing |
| 09:44 | <robpalme> | @ljharb it's true that this efficiency can be gained by deviating from ecmascript, but it's better for the behaviour to be aligned. otherwise third-party code doesn't work. so if other users of ES can benefit from this (e.g. moddable putting JSON data in ROM, or using read-only shared pages) then it could be worth standardising |
| 09:44 | <akirose> | WE ALL SEE DIFFERENT ANIMALS?! WHAT'S THE POINT |
| 09:44 | <robpalme> | V8 makes use of shared memory across processes to increase efficiency |
| 09:45 | <ljharb> | robpalme: if third-party code doesn't work tho, wouldn't that be because it needs the mutability? |
| 09:46 | <ljharb> | ryzokuken ptomato: so does this mean that the temporal spec is, barring minor editorial issues and perhaps naming bikesheds, frozen, and thus ready for review? |
| 09:48 | <robpalme> | right - but we set the tone here for the whole ecosystem. and if users become accustomed to immutability, that increases the amount of code that will be compatible |
| 09:48 | <ystartsev> | info on how to copy is now in the doc, if it happens again you can move the note down to communicate async with people |
| 09:49 | <rricard> | yep will do thanks a lot again |
| 09:52 | <shu> | robpalme: RO spaces aren't used for general frozen stuff, but distinguished RO VM-internal things like some maps and constants like NaN |
| 09:52 | <shu> | robpalme: so i wouldn't extend the argument that if JSON modules were immutable, that'd enable some kind of cross-isolate sharing |
| 09:53 | <robpalme> | sure - I wasn't trying to imply this is used for user-data today |
| 09:53 | <ystartsev> | shu: just to verify -- v8's position is "rather mutable"? |
| 09:54 | <shu> | ystartsev: leaning mutable, yeah |
| 09:54 | <ystartsev> | and this is from a user ergonomics perspective or was there also a technical reason? |
| 09:55 | <shu> | no technical reason |
| 09:55 | <ystartsev> | ok, so we differ on how this might impact users, thanks for verifying |
| 09:55 | <shu> | i'm somewhat swayed by the user expectations argument |
| 09:56 | <ystartsev> | yeah, agreed, thats why we thought a complementary api might be a good idea |
| 09:57 | <shu> | i think the difference of opinion comes down to how deeply baked in to the mental model of ESMs the idea of live bindings is |
| 09:57 | <shu> | the hazard seems to generalize to well beyond JSON modules |
| 09:57 | <shu> | unclear why we should raw the line here |
| 09:58 | <shu> | draw* |
| 09:58 | <ystartsev> | it might also be coding style -- as rob mentioned above, they copy everything. When I was programming js, this was the pattern I used as well -- so it doesn't make sense for me, as a js dev, to have it be mutable. Having it be immutable would prevent mistakes |
| 09:58 | <ystartsev> | but this is coding style, and not objective |
| 09:58 | <ljharb> | i will say that if live bindings didn't exist, it'd be a lot more reasonable to claim users would expect an immutable import |
| 09:58 | <shu> | what does the "copy everything" style mean? |
| 09:58 | <ystartsev> | that is a good argument |
| 09:58 | <rricard> | note we copy everything in our infra |
| 09:58 | <rricard> | not end users |
| 09:59 | <rricard> | rpalmer: maybe worth clarifying |
| 09:59 | <ystartsev> | the whole "soft immutability" coding style: `newState = {...oldState}` or something to that effect. Depending on the data, we might have a library method called deepCopy |
| 10:00 | <shu> | i see |
| 10:00 | <shu> | my problem is after all these years i still don't program JS |
| 10:01 | <ljharb> | shallow copies are common; deep copies are something i consider a code smell, and there's a ton of caveats and assumptions baked into libraries that offer it (i maintain two of them) |
| 10:02 | <shu> | ystartsev: but anyway i won't really push back either way, immutable or not |
| 10:02 | <ystartsev> | usually you don't end up doing deep copies (or at least i have no memory from the last few years of doing that). But at some point I did cross a deep copy, though in tests |
| 10:03 | <robpalme> | @shu: Does that imply Chrome would accept either way? |
| 10:03 | <ljharb> | ystartsev: good point, i have often used it in test fixtures |
| 10:03 | <ystartsev> | i mean, similar case here: if its mutable or immutable we don't have a strong opinion. leaning to immutable, suggesting that an api exists to copy the object if it does |
| 10:03 | <ystartsev> | we had a discussion of json.copy before we came to the conclusion of something like `import` instead |
| 10:04 | <rricard> | we are only 2 note takers we can continue like this but a third one would be appreciated |
| 10:04 | <ljharb> | hmm - i suppose `JSON.parse(JSON.stringify(obj))` is an idiomatic way to deep copy a JSON object, frozen or not |
| 10:04 | <ljharb> | how fast/slow is that in engines? i've never measured |
| 10:05 | <ystartsev> | gunna jump on the notes, excuse me |
| 10:05 | <rricard> | np thanks |
| 10:05 | <akirose> | someone is a pumpkin |
| 10:07 | <rricard> | bakkot: add temple => temporal autoconvert |
| 10:07 | <shu> | robpalme: afaik yes |
| 10:08 | <robpalme> | woooooooo |
| 10:08 | <robpalme> | thank you |
| 10:09 | <robpalme> | (that woo is an individual delegate woo, not a chair group woo) |
| 10:11 | <Bakkot> | rricard done, though maybe too late now |
| 10:11 | <rricard> | people are going to talk about temples some more |
| 10:15 | <littledan> | Richard has clarified that he's not asking for the emoji thing. i think that should be taken down. |
| 10:15 | <sffc> | Where am I supposed to find the new temperature check emoji? I don't see them on tcq |
| 10:15 | <shu> | sffc: the chair group puts it up when a champion asks for it |
| 10:15 | <shu> | or when someone asks for it, i guess, dunno if it has to be champion |
| 10:17 | <ljharb> | gibson042: is there a specific part of the existing proposal that you're worried about right now? (that i missed) |
| 10:17 | <ljharb> | or is this a general philosophy question |
| 10:19 | <gibson042> | the latter... I'm not concerned with any given approach, but consider it important that TC39 not repeat the de facto squatting that came from Java |
| 10:19 | <ljharb> | gotcha |
| 10:20 | <gibson042> | and it would be bad if we followed e.g. an IETF draft for "[c=Japanese]" that *their* process transforms into "[cal=japanese]" before publication |
| 10:22 | <gibson042> | "The best laid schemes o' mice and men gang aft a-gley" |
| 10:27 | <michaelficarra> | ryzokuken: you are still presenting |
| 10:27 | <ryzokuken> | michaelficarra: sorry! |
| 10:27 | <ryzokuken> | stopped presenting now |
| 10:29 | <ystartsev> | am i the only one with weird screen? |
| 10:29 | <ryzokuken> | no |
| 10:30 | <ryzokuken> | it looks clipped for me |
| 10:34 | <littledan> | (I've seen issues with the emoji reacts not popping up on mobile sometimes) |
| 10:38 | <littledan> | OK, Surma confirmed with me that the 1 PM timeslot works for JS module blocks |
| 10:38 | <ljharb> | sad i'll miss it :-( |
| 10:39 | <rricard> | sorry had to walk away from the computer for a bit |
| 10:39 | <akirose> | do we have enough editors? |
| 10:39 | <rricard> | back |
| 10:39 | <akirose> | rricard: thank you ♥️ |
| 10:40 | <rricard> | devin transcription is gooood |
| 10:40 | <drousso> | (☞ﾟヮﾟ)☞ |
| 10:40 | <shu> | robpalme: akirose: surma says he'll be ready for 1pm slot |
| 10:41 | <robpalme> | ty |
| 10:41 | <shu> | oh i missed what littledan said above already |
| 10:41 | <ljharb> | drousso: a query API combined with a hardcoded list basically === an enumeration api |
| 10:41 | <ljharb> | drousso: just, less ergonomic for good actors. |
| 10:41 | <littledan> | yeah it seems like nobody had told him about the 11:30 scheduling for his topic |
| 10:42 | <littledan> | it's a bit hard to communicate this given how dynamic the schedule (necessarily) is |
| 10:42 | <littledan> | I can't believe the chairs manage to handle it with all the different things that come up |
| 10:42 | <akirose> | yeah but... that was specifically in that time slot to accomodate various scheduling constraints |
| 10:42 | <akirose> | including his |
| 10:42 | <littledan> | right, we just forgot to tell him the result |
| 10:42 | <littledan> | I think you did a good job |
| 10:43 | <littledan> | this was more on me |
| 10:43 | <akirose> | ooooh got it he wasn't looking at the reflector actively |
| 10:43 | akirose | curtseys |
| 10:43 | <littledan> | right, he's not a frequent TC39 attendee |
| 10:48 | <littledan> | gibson042: We all agree that it's important for us to not repeat the de facto squatting. I'd go further and say, it's a Stage 3 prerequisite that we get somewhat far along in the standards discussions. I think an IETF draft is a good checkpoint here; I don't know exactly what the Stage 4 prerequisite should be worded as |
| 10:54 | <littledan> | you can always monkey-patch on top of these APIs to add more data |
| 10:54 | <littledan> | also browsers and other JS environments often have strong timezone update mechanisms to get the freshest data directly in the host |
| 10:55 | <rricard> | bakkot: Intel to Intl |
| 10:55 | <rricard> | actually |
| 10:55 | <michaelficarra> | yeah our Intel delegates may not appreciate that |
| 10:55 | <rricard> | yulia did you mean intel, the company this time? |
| 10:56 | <ljharb> | i believe she said Intl |
| 10:56 | <Bakkot> | will do as soon as there's a gap in the audio |
| 10:56 | <rricard> | where did leo start? |
| 10:57 | <leobalter> | let me see the notes |
| 10:58 | <shu> | michaelficarra: when was the last time we had an Intel delegate? |
| 10:58 | <ljharb> | shu: we did for SIMD, and a number of meetings after |
| 10:59 | <ljharb> | but it's been awhile |
| 10:59 | <shu> | yeah i feel like at least 2 years |
| 10:59 | <littledan> | yeah, we had Peter for a while |
| 11:00 | <rricard> | bakkot can you stop |
| 11:00 | <Bakkot> | done |
| 11:00 | <rricard> | thanks |
| 11:00 | <ljharb> | Bakkot: does the transcription bot always insert at EOF, or can it be made to insert before a marker, so there's a scratch space at the bottom of the doc? |
| 11:00 | <Bakkot> | always EOF |
| 11:00 | <rricard> | as usual won't be able to be an editor this afternoon |
| 11:01 | <Bakkot> | gdocs API claim to support insertions anywhere but interacts very poorly with people editing the doc live |
| 11:04 | <gibson042> | littledan: agreed. If it looks like IETF will be the body to which TC39 defers, then I would say publication of a Standards Track RFC would be the ideal Stage 4 prerequisite |
| 11:05 | <littledan> | gibson042: That makes sense but I don't know what exactly constitutes a "standards track RFC" and how the calsify WG ends up working. I feel like this comes down to details that we'll learn as we work with them more. |
| 11:06 | <littledan> | as Ujjwal explained in his presentation, and as we've been discussing with you in the champion group meetings, this whole thing is already the plan |
| 11:14 | <littledan> | I feel like, even if the committee's temperature were flexible on requiring that we go through standards, we should still do it, to be safe |
| 11:15 | <gibson042> | https://tools.ietf.org/html/bcp9#section-4 |
| 11:15 | <littledan> | (Someone who works in IETF told me the official documentation doesn't really match their practice) |
| 11:16 | <littledan> | so I think this is just something we have to figure out the details of as we go along with IETF Calsify WG, and judge based on what we learn there, which point would be "standard enough" for Stage 4 |
| 11:16 | <littledan> | I agree that it should be pretty standard and stable and agreed-on as a Stage 4 prerequisite |
| 11:43 | <littledan> | and the idea will be to have a solid draft that is moving along in reviews with IETF as a Stage 3 prerequisite |
| 11:48 | <gibson042> | perfect |
| 11:58 | <robpalme> | we will restart in 2 mins! |
| 11:58 | <robpalme> | Surma is in pole position, ready to go |
| 12:10 | <michaelficarra> | metaproperties could be used to avoid the NLTH problem |
| 12:10 | <michaelficarra> | something like new.module { … } |
| 12:11 | <shu> | i guess you care about typing `module\n{`? |
| 12:12 | <michaelficarra> | who is the "you" here? |
| 12:13 | <michaelficarra> | only people who omit semis would care about that |
| 12:13 | <shu> | you, michael ficarra |
| 12:14 | <michaelficarra> | no, not at all |
| 12:14 | <michaelficarra> | but it was brought up in the slides that we would need a NLTH for the shown syntax |
| 12:15 | <michaelficarra> | and I was saying that there's an alternative: metaproperties |
| 12:15 | <rbuckton> | if the line break is important, we could also investigate a "keyphrase", like `inline module\n{` |
| 12:16 | <rbuckton> | where there's an NLT between `inline` and `module`, but not between `module` and `{`, similar to `async function` |
| 12:20 | <drousso> | isn't `module` a reserved keyword in strict mode? |
| 12:20 | <littledan> | haha what a confluence of conditions... |
| 12:20 | <littledan> | we have too many Daniel's! |
| 12:21 | <akirose> | are we at more-daniels-than-women today |
| 12:21 | <akirose> | i think we are |
| 12:21 | <littledan> | Shu's comment should precede mine |
| 12:21 | <littledan> | I guess scope = global object? |
| 12:21 | <shu> | yeah, it has to be global object |
| 12:22 | <littledan> | we hear some typing noise |
| 12:22 | <robpalme> | Realm! |
| 12:22 | <littledan> | I feel like... if tooling is responsible for configuring different files for different global environments, maybe there can be a solution on a tooling level for this. Magic comments? |
| 12:23 | <robpalme> | // @ts-realm:worker |
| 12:23 | <rbuckton> | I don't think `module` has ever been reserved? `package` is though. |
| 12:25 | <drousso> | oh hmmm |
| 12:30 | <littledan> | note that it's totally kosher in HTML to let something be postMessage'd but not IndexedDB-serialized |
| 12:32 | <littledan> | this is based on the forStorage argument of the serialization algorithm https://html.spec.whatwg.org/multipage/structured-data.html#serializable |
| 12:33 | <brad4d> | Daniel Rosenwasser - please add yourself with abbreviation to attendees in today's notes |
| 12:33 | <brad4d> | I've just updated your quotes in the notes doc to DRR (they were attributed to DRO by mistake) |
| 12:33 | <shu> | sffc: i had vision talk yesterday on your exact topic, IIUC |
| 12:34 | <akirose> | sffc: shu's slides for that were—and this is a bold statement—the best he's ever done |
| 12:35 | <robpalme> | that's not bold - it's fact |
| 12:35 | <shu> | sffc: https://docs.google.com/presentation/d/1kqtsJfLVC-Nmcm2sveMRdJPjurwKKiiCGilK2_ladpw/edit?usp=sharing |
| 12:35 | <shu> | can't claim credit for the theme, i found that theme |
| 12:35 | <sffc> | shu: cool! Yeah, I took a rain check for that part of the meeting. Thanks for flagging :) |
| 12:36 | <shu> | no worries, sorry if i implied any judgment about missing the meeting |
| 12:37 | <drousso> | i don't know if Surma is in IRC, but this is awesome and i'd love to help out if that's desired :) |
| 12:40 | <rbuckton> | I am also interested in this, especially in how shu wants to tie it in to concurrency as well as some of the ongoing discussions about typed objects. |
| 12:44 | <sffc> | "Vision for concurrent JS" looks really cool; I'm sorry I missed it! I'll read up on the notes |
| 12:44 | <littledan> | +100 for merging; this is a significant improving in clarifying and documenting our process |
| 12:44 | <michaelficarra> | oh boy, I did not know we were going to be agreeing to process doc changes today |
| 12:45 | <littledan> | the slides have been posted since before the deadline, indicating that they would ask for consensus |
| 12:45 | <robpalme> | this was raised in the previous meeting, michael |
| 12:47 | <littledan> | Yulia explained that there aren't substantial changes since last time |
| 12:47 | <michaelficarra> | I just thought it was another update |
| 12:48 | <littledan> | WeakRefs are a great example of why "rejected" is not a useful concept--I thought Waldemar was going to talk about this :) |
| 12:49 | <michaelficarra> | can't rejection just be a signal to the chairs to not allow something substantially similar to this be brought forward again? |
| 12:49 | <littledan> | I think "inactive proposals with documented objections" is a good way to represent this |
| 12:49 | <littledan> | I don't really understand what the role for chairs that you're proposing is |
| 12:49 | <robpalme> | notes from previous meeting: |
| 12:49 | <robpalme> | https://github.com/tc39/notes/blob/master/meetings/2020-09/sept-22.md#process-document-clarifications |
| 12:50 | <michaelficarra> | littledan: one of the primary responsibilities of the chairs is to decide what the committee does work on during plenary |
| 12:59 | <littledan> | +1 to improving documentation about the status of all the proposals, and doing post-mortem discussions as a committee, if this is what msaboff_ is proposing |
| 13:00 | <littledan> | I think this is a good thing to discuss in a future process discussion; I don't think it needs to be coupled to this one, which is focused on documenting our existing process |
| 13:05 | <chicoxyzzy> | +1 |
| 13:05 | <chicoxyzzy> | also it would be nice to clarify https://github.com/tc39/process-document/issues/4#issuecomment-729657851 |
| 13:06 | <shu> | msaboff_: interesting point, i think that depends on removal is wholesale removal or reworking the feature |
| 13:07 | <shu> | msaboff_: cf my removing subclassing proposal, which i'm taking through the staging process, but i don't really know what that means |
| 13:10 | <msaboff_> | littledan Documentation is part of what i was asking for, but I think we should acknowledge that some proposals will likely never advance. |
| 13:10 | <msaboff_> | shu I do agree with the point you just posted in TCQ |
| 13:10 | <shu> | cool |
| 13:15 | <michaelficarra> | mathiasbynens: do you know what Markus' preferred initials are? |
| 13:15 | <michaelficarra> | also please send a PR to delegates.txt or ask him to do so |
| 13:18 | <mathiasbynens> | it's already there; MWS |
| 13:18 | <mathiasbynens> | https://github.com/tc39/notes/pull/86 |
| 13:18 | <michaelficarra> | oh I hadn't refreshed since the start of the meeting |
| 13:18 | <michaelficarra> | I see it now |
| 13:18 | <mathiasbynens> | 👍🏻 |
| 13:20 | <gibson042> | I love this capability, but resolving syntax seems like it's going to be difficult |
| 13:21 | <michaelficarra> | yeah, [a—b] already has a meaning |
| 13:21 | <mathiasbynens> | gibson042: depending on what syntax the committee would prefer, we could introduce a new flag |
| 13:21 | <gibson042> | :( |
| 13:21 | <Bakkot> | isn't this the unicode consortium has a recommendation for? |
| 13:21 | <mathiasbynens> | agreed we definitely don't wanna break back-compat |
| 13:21 | <msaboff_> | Yeah, I'm worrying about syntax as well. |
| 13:21 | <rbuckton> | Oniguruma uses `&&` for intersections in character classes |
| 13:21 | <Bakkot> | unicode consortium has so much stuff in their regexes |
| 13:21 | <rbuckton> | And `[]` for nested sets |
| 13:22 | <rbuckton> | https://github.com/kkos/oniguruma/blob/cd8357ff348a61084543afc87f7f685906c03d39/doc/RE#L205-L215 |
| 13:22 | <mathiasbynens> | the syntax in the slides is what UTS18 + most implementations use, but UTS18 allows both `&&` and `&` iirc — I think whatever we choose we'd want to pick just one |
| 13:23 | <msaboff_> | I don't know is therre are any fully conforming implementations of the Unicode consortium suggested RegExp in UTS18 - https://unicode.org/reports/tr18/ |
| 13:23 | <michaelficarra> | we only have ~1 person editing notes btw and they are getting a bit incomprehensible |
| 13:23 | <rbuckton> | `&` is problematic on its own, since `/a&b/` is already a valid RegExp. So is `&&` for that matter. If we used either we might need a flag to opt into the behavior |
| 13:24 | <mathiasbynens> | rbuckton: note that the problem is slightly smaller in scope, since only the syntax within [] would change |
| 13:24 | <mathiasbynens> | so not /a&b/ but /[a&b]/ |
| 13:24 | <gibson042> | which also is already valid |
| 13:24 | <msaboff_> | rbuckton The syntax could be limited to inside character classes, which may make the syntax problem possibly easier. |
| 13:25 | <mathiasbynens> | gibson042: i know |
| 13:25 | <rbuckton> | Ah, yeah, that's true. And `[a&&b]` is less likely to exist due to the fact two `&` characters in a class is redundant. |
| 13:25 | <littledan> | I love that we keep working on making RegExps better in TC39 |
| 13:25 | <mathiasbynens> | rbuckton: indeed. (but even the redundant form is valid so your point stands) |
| 13:25 | <wsdferdksl> | All of these are problematic. /[[0-9]]/ currently means a character class containing '[' or one of the ASCII digits, followed by a ']' character. |
| 13:26 | <msaboff_> | Wow, RexExp and readable in the same sentence! |
| 13:26 | <rbuckton> | littledan: I'm also considering bringing some RegExp features to TC39 in a future meeting |
| 13:26 | <wsdferdksl> | Also, /a--b/ means a range starting with 'a' and ending with a '-', or a 'b' character. |
| 13:27 | <littledan> | bterlson deserves a lot of the credit for kicking this off with his classic "RegExp buffet" presentation. There's still other things there that could be picked up! I wish I could find the slides. https://github.com/tc39/notes/blob/master/meetings/2015-11/nov-17.md#regexp-buffet |
| 13:27 | <wsdferdksl> | Sorry, meant /[a--b]/. |
| 13:27 | <gibson042> | unfortunately, the only reserved characters in a character class are `\` and `]` and `-` |
| 13:27 | <gibson042> | everything else just represents itself |
| 13:27 | <littledan> | one big thing that would be great in JS RegExps would be a template tag constructor form, so you could interpolate in literal strings or compose different RegExps |
| 13:27 | <mathiasbynens> | wsdferdksl: thanks for pointing out those examples. i think these show that we'd either need A) a flag or B) wildly different syntax that somehow doesn't have these problems |
| 13:27 | <rbuckton> | We may end up needing a flag, but I'd definitely use this. |
| 13:28 | <littledan> | if anyone is interested in championing that, I'd be happy to connect you to past discussions about it, do reviews, etc |
| 13:28 | <michaelficarra> | same, I am interested in a RegExp template tag |
| 13:29 | <littledan> | Can we invite `surma` here? He's in #tc39 |
| 13:29 | <gibson042> | maybe ECMAScript can introduce a "U" flag for UTS18 |
| 13:29 | <akirose> | Markus is looking for the mood of the committee, temperature check is open |
| 13:29 | <msaboff_> | Not another mode flag ;( |
| 13:29 | <gibson042> | I don't even know if I'm joking |
| 13:29 | <mathiasbynens> | `/./🇺` |
| 13:30 | <michaelficarra> | please no flags for this |
| 13:30 | <mathiasbynens> | michaelficarra: any ideas on how to avoid having to add a flag? |
| 13:30 | <mathiasbynens> | i can't think of syntax that would work off the top. would be great if there was a way |
| 13:32 | <michaelficarra> | yeah that's why I don't think this is good for syntax |
| 13:32 | <michaelficarra> | see my queue entry |
| 13:33 | <michaelficarra> | the pattern grammar doesn't have much room for extension without flags, and I really don't want to add a flag for every new (and infrequently used) regexp feature |
| 13:34 | <rbuckton> | we could theoretically come up with a "strict mode" flag for regexp and reserve a set of characters that give us room to expand the syntax inside of a regexp. |
| 13:34 | <michaelficarra> | who is this Mark that is speaking? |
| 13:34 | <msaboff_> | You could introduce new syntax using some existing \ escape (this makes the most sense for unicode flagged expressions where escapes as reserved). |
| 13:34 | <robpalme> | Markus Scherer is speaking |
| 13:35 | <gibson042> | possibly `/[\U…]/u` |
| 13:35 | <msaboff_> | I believe he represents Google in the Unicode Consortium |
| 13:36 | <msaboff_> | Sure or \U[...] |
| 13:36 | <gibson042> | yep |
| 13:36 | <gibson042> | I think this is possible |
| 13:37 | <robpalme> | I remain impressed with meeting attendance. We have 36 now. |
| 13:40 | <rbuckton> | I could see the `u` giving us this flexibility, with caveats. For example, intersection using `\I{A,B}`to intersect the character classes of A and B (i.e., `/[\I{\p{Letter},\p{Lowercase}}]/u`) |
| 13:40 | <rbuckton> | Not the prettiest, but its viable. |
| 13:41 | <sffc> | Mark is Mark E. Davis: https://en.wikipedia.org/wiki/Mark_Davis_(Unicode) -- I opened a PR to add his acronym MED: https://github.com/tc39/notes/pull/87 |
| 13:42 | <shu> | i hope we didn't try to explain unicode to him |
| 13:45 | <littledan> | you have to be pretty good in a field to have a wikipedia page with a disambiguation naming that field |
| 13:45 | <msaboff_> | Isn't Mark E Davis the Unicode Editor or similar? |
| 13:46 | <msaboff_> | gibson042 Good on you to place syntax in TCQ!!! |
| 13:47 | <msaboff_> | RegExp pattern syntax at that. |
| 13:47 | <gibson042> | ✔ |
| 13:49 | <mathiasbynens> | yeah that's Mark alright |
| 13:49 | <mathiasbynens> | he's only the President of the Unicode Consortium, nbd |
| 13:50 | <shu> | yeah but can he name every unpaired surrogate |
| 13:51 | <mathiasbynens> | U+D83D U+DE02 |
| 13:54 | <mathiasbynens> | gibson042: or even `\U{{[A]--[B]}}` and `\U{{[A]&&[B]}}` etc. |
| 13:55 | <mathiasbynens> | heck we could even do `\UnicodeSet{…}` |
| 13:56 | <gibson042> | exactly |
| 13:56 | <mathiasbynens> | love it |
| 14:00 | <gibson042> | if Chrome can ship Scroll to Text Fragment as "#:~:text=prefix-,startText,endText,-suffix" and sleep at night, we can do this kind of damage |
| 14:02 | <mathiasbynens> | https://github.com/mathiasbynens/proposal-regexp-set-notation/issues/2 |
| 14:02 | <Bakkot> | ok bedtime |
| 14:02 | <msaboff_> | Going to bed as well... |
| 14:02 | <Bakkot> | transcription worked noticibly better today than the last two days, I think! |
| 14:04 | <michaelficarra> | we officially hit 50 poages! |
| 14:04 | <michaelficarra> | *pages |
| 14:05 | <devsnek> | mathiasbynens but \U has to be the name of a unicode character |
| 14:05 | <devsnek> | \U{HEAVY BLACK CHECK MARK} |
| 14:05 | <mathiasbynens> | devsnek: this doesn't prevent us from doing that |
| 14:06 | <devsnek> | hmm I guess you're technically not wrong |
| 14:06 | <Bakkot> | Words 27759 |
| 14:06 | <rbuckton> | we can use any unused escape in `u`-mode, so there's some flexibility here. |
| 14:06 | <devsnek> | my favourite part of the bible |
| 14:08 | <robpalme> | we use timestamps to track agenda items, e.g. mark 10:15-10:30. |
| 14:09 | <devsnek> | 🙏 |
| 14:09 | <devsnek> | thou shalt not share wet objects with dry realms |
| 14:09 | <robpalme> | one time i started using them to look up biblical references and freaked myles out by making up a super plausible psalm on consensus |
| 14:10 | <devsnek> | lol |
| 14:14 | <michaelficarra> | rbuckton: this is assuming you want this feature to only be usable in strict mode code |
| 14:15 | <rbuckton> | what feature? RegExp sets and intersections? I was talking about a strict-mode flag for RegExp, which apparently `u` satisfies. |
| 15:29 | <devsnek> | not strict enough |
| 17:10 | <ystartsev> | shu: regarding your question about intl enumeration, i got the following answer: "large API surface - we are entering the world of an API that will return 50-100 items depending on the "query" that are all fingerprintable and the very intention of the API is to let apps adjust their behavior depending on the returned values. Which means that changes to what we return may become web-compat issues." |
| 17:54 | <gibson042> | devsnek: in what sense is /u not strict enough? Tokenization is not affected by introduction of a new backslash sequence. |
| 18:29 | <devsnek> | gibson042: it allows annex b |
| 18:43 | <gibson042> | which doesn't affect tokenization AFAICT, and the relevant changes to the regular expression grammar are strictly applied to non-/u expressions (which is why `(/\U[\p{N}]/u)` is a SyntaxError while `(/\U[\p{N}]/)` is not) |
| 18:44 | <Bakkot> | yeah, to quote: "none of these [Annex B] extensions change the syntax of Unicode patterns recognized when parsing with the [U] parameter present on the goal symbol." |
| 21:03 | <shu> | ystartsev: thanks, is that... implementation difficulty? |
| 21:03 | <shu> | those sound like valid concerns, but not implementability concerns |
| 21:06 | <rkirsling> | true web compat in the presence of changing locale data is probably an impossible dream anyway |
| 21:11 | <rkirsling> | (which isn't to say it would stop users from submitting bugs based on naive assumptions of stability though) |
| 21:22 | <bradleymeck> | rkirsling: swapping locales generally requires restarting browsers already |
| 21:23 | <rkirsling> | oh, I didn't even mean default locale |
| 21:24 | <rkirsling> | like, so many of the intl402 tests in test262 are basically CLDR regression tests, even though ECMA-402 itself doesn't care what locale data you actually have available |