| 00:55 | <ljharb> | confirmed - when i sign into teams with my microsoft account, i have no ability to change my name or profile picture just for teams, it's forced to be whatever my global account's name/picture are. i had to sign out so i could customize my display name |
| 00:59 | <rkirsling> | yeah I'm trying my work computer today so I'll see if it's different this way tooo |
| 00:59 | <rkirsling> | -o |
| 01:02 | <littledan> | has the meeting started yet? I'm having trouble getting in |
| 01:02 | <rkirsling> | they're managing entry individually |
| 01:04 | <wsdferdksl> | We just started |
| 01:05 | <littledan> | OK, I'm still seeing "When the meeting starts, we'll let people know you're waiting." |
| 01:05 | <wsdferdksl> | The chairs requested that only the chairs let folks in |
| 01:06 | <littledan> | OK, it doesn't seem like Teams is really working out, either from a technical or moderation perspective |
| 01:09 | <rkirsling> | littledan: I don't disagree :-/ |
| 01:09 | <littledan> | oh, I think I was going into the wrong link, and that's why it wasn't loading |
| 01:09 | <littledan> | so, I can't blame Teams for this :) |
| 01:15 | <rkirsling> | I love the use of "yadda yadda" in a proposal explanation |
| 01:17 | <michaelficarra> | non-BMP *scripts* is the more appropriate term |
| 01:21 | <haxjs> | Let's split string.p.item to a follow-on proposal! |
| 01:24 | <rkirsling> | haxjs: if it gets removed from this proposal, then yeah, anybody could champion it separately |
| 01:26 | <haxjs> | I think maybe we can use codepoint-safe access on string.p.item, but it obviously need further discussion |
| 01:27 | <littledan> | our language does support grapheme clusters now, thanks to Intl.Segmenter! :) |
| 01:27 | <devsnek> | v8BreakIterator :) |
| 01:27 | <littledan> | not like that! |
| 01:27 | <keith_miller> | ljharb: It would have a perf impact if you did it enough |
| 01:27 | <ljharb> | noted |
| 01:28 | <littledan> | I can understand the argument that we should have .item(), but I don't understand the argument that, without it, the proposal isn't ready for Stage 3 |
| 01:28 | <keith_miller> | Maybee you could optimize out the array but I doubt any engine does that |
| 01:28 | <littledan> | strings are missing other things that logically *could* be defined on them, for example map |
| 01:28 | <rkirsling> | re-rope-ification? :p |
| 01:28 | <devsnek> | translate |
| 01:28 | <michaelficarra> | are the Intl people working on a grapheme cluster iterator? |
| 01:29 | <devsnek> | michaelficarra: Intl.Segmenter |
| 01:29 | <rkirsling> | yeah it includes iteration |
| 01:29 | <michaelficarra> | it has a grapheme cluster mode? |
| 01:29 | <michaelficarra> | I only remember it doing like word/sentence stuff |
| 01:29 | <devsnek> | yes! and its stage 3! |
| 01:29 | <michaelficarra> | cool |
| 01:30 | <rkirsling> | admittedly I never thought to test it with emoji but now I want to |
| 01:31 | <ljharb> | jorendorff: lol, they might be less confused about what item does - most users don't know about code points or graphemes or whatnot |
| 01:31 | <Bakkot> | the benefit of adding this is purely for developers; the cost paid for the bugs is paid by users |
| 01:32 | <Bakkot> | there are more of the latter |
| 01:32 | <Bakkot> | by a lot |
| 01:32 | <ljharb> | i'm very skeptical to the implication that the existence of `item` on strings is going to increase the likelihood that these sort of bugs will happen |
| 01:32 | <keith_miller> | jorendorff: But yeah you can't do random access on a UTF-16 without it being O(n) |
| 01:32 | <keith_miller> | As far as I know |
| 01:32 | <keith_miller> | Which is a big O.o to 99% of JS users... |
| 01:33 | <ljharb> | s/skeptical to/skeptical of |
| 01:33 | <rkirsling> | devs not knowing about code points doesn't mean it's okay that they don't know about code points |
| 01:33 | <apaprocki> | (Like timezones) |
| 01:33 | <michaelficarra> | Bakkot: users that are usually disconnected from the development process and will be invisible |
| 01:33 | <ljharb> | rkirsling: sure, agreed, but it does mean they're less likely to be confused about `.item`, and if they know about code points, they'd already know about the difference presumably? |
| 01:34 | <Bakkot> | michaelficarra right |
| 01:34 | <michaelficarra> | (clarification: their pain will be invisible, not the users) |
| 01:35 | <gibson042> | `Array.from( (new Intl.Segmenter("en", {granularity: "grapheme"})).segment("Moto\u0308rhead") )` |
| 01:35 | <littledan> | how about a straw poll? |
| 01:36 | <rkirsling> | littledan: vocally? |
| 01:36 | <littledan> | (I agree with Mark's take) |
| 01:36 | <rbuckton> | We need better ways to measure and manipulate strings for all 3 scenarios (code unit, code point, grapheme cluster) |
| 01:36 | <rkirsling> | I really want to see this advance either way |
| 01:36 | <gibson042> | agreed |
| 01:37 | <Bakkot> | ljharb if we leave it out, and people reach for it, they might learn why it's not there and learn the correct thing to do |
| 01:37 | <Bakkot> | if we add it, there is no chance of that |
| 01:37 | <michaelficarra> | I don't think indexing on either code points or grapheme clusters is a good idea, since it's a linear operation |
| 01:37 | <Bakkot> | they will be guaranteed to ship the bug |
| 01:37 | <haxjs> | maybe we could land item() but add codepoint-safe methods like codePointItem(), codePointSlice() etc. |
| 01:38 | <keith_miller> | haxjs: I'd prefer we do something like String("content", { format: "utf-32" }) |
| 01:38 | <leobalter> | start with Assertions please :) |
| 01:38 | <rkirsling> | haxjs: I mean you have a point there; if the key is that `item` and `[]` are consistent then having other means of dealing with code points feels more consistent |
| 01:38 | <mmarchini> | Computers are hard |
| 01:38 | <ljharb> | Bakkot: that is certainly possible. i am very skeptical they'd do any more thinking about it than just doing `str.slice(-1)[0]` or `str[str.length - 1]` |
| 01:38 | <haxjs> | keith_miller: I also support that idea! |
| 01:38 | <rbuckton> | i.e., `.codePointCount`, `.graphemeCount`, `.nthCodePoint(n)`, `.nthGrapheme(n)`, `.isLowSurrogate(i)`, `.isHighSurrogate(i)`, etc. |
| 01:38 | <ljharb> | haxjs: i like that idea |
| 01:38 | <keith_miller> | haxjs: That said, it's way more work for browsers lol |
| 01:39 | <keith_miller> | but it's also much faster in the long run |
| 01:39 | <devsnek> | rbuckton: `nthWord`, `nthSentence` |
| 01:39 | <keith_miller> | since you don't have to have O(n) codePointItem() |
| 01:39 | <brad4d> | did we skip item #20 on tcq or did I just miss it somehow? |
| 01:39 | <devsnek> | brad4d: skipped |
| 01:39 | <rkirsling> | rbuckton: that's a whole new library at that point though |
| 01:39 | <rbuckton> | devsnek: Those would be `Intl` features :) |
| 01:39 | <Bakkot> | ljharb certainly some would, but also almost certainly some wouldn't |
| 01:39 | <rkirsling> | ahhh |
| 01:39 | <Bakkot> | some might, e.g., do `[...foo].item(-1)` |
| 01:40 | <devsnek> | rbuckton: graphemeCount and nthGrapheme are intl as well |
| 01:40 | <Bakkot> | which is at least more correct |
| 01:40 | <ljharb> | Bakkot: and then they'd still cause bugs for users, just slightly less often. |
| 01:40 | <Bakkot> | right! |
| 01:40 | <Bakkot> | which is good! |
| 01:40 | <Bakkot> | fewer bugs is better than more bugs! |
| 01:40 | <rbuckton> | rkirsling: Perhaps, but we constantly come back to "string indexing is bad". |
| 01:40 | <keith_miller> | Bakkot: Oh god at `[...foo].item(-1)` lol |
| 01:40 | <devsnek> | Bakkot: so you admit you're trying to cause bugs! (/s) |
| 01:40 | <ljharb> | Bakkot: unless more bugs leads to them discovering the true nature of code units/points and grapheme clusters, sooner |
| 01:40 | <ljharb> | Bakkot: just like you're claiming the "bug" that item is absent might |
| 01:40 | <Bakkot> | ljharb what |
| 01:41 | <ljharb> | (not that i believe it will cause more bugs, i'm just working with your hypothetical :-p ) |
| 01:41 | <Bakkot> | you really aren't |
| 01:41 | <Bakkot> | the likelihood of them discovering this fact as a consequence of causing harm to users is a direct function of the amount of harm caused to users, which will happen over a shorter or larger period of time depending on how bad their implementation is |
| 01:42 | <Bakkot> | but the thing I am saying is that if we leave it out they might find it (or reach for something which works better, even if not perfectly _before_ causing harm to users), which there is no chance of if we include it |
| 01:43 | <Bakkot> | (parentheses are messed up there sorry) |
| 01:44 | <shu> | littledan: are those slides shared somewhere? |
| 01:44 | <littledan> | shu: Yes, linked from the agenda |
| 01:44 | <littledan> | I'll copy that slide into the notes as the conclusion |
| 01:44 | <shu> | cool thanks |
| 01:44 | <rkirsling> | I think the biggest thing is that having S.p.item exist, with that name, and not be about code units, would be block-worthy |
| 01:45 | <jorendorff> | yes, that would be ... bad |
| 01:45 | <ljharb> | rkirsling: i agree with that for sure |
| 01:45 | <Bakkot> | sure but that's not on the table |
| 01:46 | <jorendorff> | there's a pattern with TC39 where we must decide anew each time if we are going to try to protect people from the language's pre-existing warts |
| 01:46 | <rkirsling> | right but if somebody made a popular library that did the equivalent of [...foo].item(-1), that could be a worse reality |
| 01:47 | <jorendorff> | i don't think we should make a habit of worrying, every time we decide _not_ to do something, that a web developer will do something worse |
| 01:47 | <jorendorff> | spoiler: they will do something worse anyway |
| 01:47 | <rkirsling> | I accept that counterpoint XD |
| 01:47 | <jorendorff> | :D |
| 01:49 | <mpcsh> | a friendly reminder to everyone of the existence of #tc39-beginners! if you're willing, please join and help clarify topics for our newcomers ♥ |
| 01:51 | <shu> | jorendorff: the existence of a bad thing is a stronger argument than hypothetical worries. in this case the argument's kinda weak, but was stronger for TLA, since there was sufficient evidence of people default exporting a thenable or something? i forget what the thing was but it was bad, and convinced me it was worse than having TLA |
| 01:53 | <rkirsling> | basically my point here is that I hear Kevin's worries but I at least feel okay with the fact that we're doing the obvious thing |
| 01:56 | <ljharb> | shu: re your queue reply, happy to wordsmith with any of the 3 alternatives, and i still strongly and nonblockingly prefer alt 1 |
| 01:56 | <shu> | ljharb: but my suggestion is to change what alt 1 says |
| 01:56 | <shu> | does alt 1 for you generalize to "relax for some subset of hosts"? |
| 01:56 | <ljharb> | shu: i'm ok with that, pending wordsmithing :-) |
| 01:56 | <shu> | okay |
| 01:57 | <shu> | thanks |
| 01:57 | <ljharb> | shu: iow i want the default/common case to be the stronger constraint |
| 01:57 | <ljharb> | devsnek: eg, 2 dynamic imports one after the other |
| 01:58 | <devsnek> | hm ok |
| 02:01 | <akirose> | is it possible for us to move on beyond this topic |
| 02:01 | <littledan> | akirose: This is really the key topic that we've been debating about |
| 02:01 | <akirose> | k |
| 02:13 | <shu> | ljharb: i think dan's got a good point. istm your actual worry is the "evaluator attributes" that was split out; the edge cases are going to exist regardless |
| 02:14 | <ljharb> | shu: right but without the constraint, there's nothing preventing an implementation from making import assertions *be* evaluator attributes |
| 02:15 | <devsnek> | evaluator attributes should be illegal |
| 02:16 | <shu> | ljharb: the "no reinterpretation" constraint is still there and uncontroversial! |
| 02:17 | <devsnek> | temporal!! |
| 02:17 | <shu> | you'd have to squint *pretty* hard to use import assertions like evaluator attributes and say you conform to "no reinterpretation" |
| 02:17 | <shu> | like, we would just shoot it down |
| 02:17 | <devsnek> | i don't put squinting very hard past the js ecosystem |
| 02:19 | <ljharb> | shu: that is fair. but it also seems really unfortunate that all engines would have less usability for users due to an html spec editor's preference :-/ |
| 02:19 | <leobalter> | I wanted to watch this one - Intl Enumeration - but I'm gonna need to have a break for proper parenting time |
| 02:20 | <leobalter> | audio is on, I'll try to catch keywords |
| 02:20 | <ljharb> | leobalter: it's json modules now |
| 02:20 | <leobalter> | ljharb: yeah, I just spent my luck today |
| 02:20 | <shu> | ljharb: it affects edge cases, not general usability |
| 02:21 | <shu> | ljharb: if it did affect general usability i'd fight with html harder on this |
| 02:21 | <ljharb> | shu: since hosts can play with adding arbitrary assertions, i suspect it'll get way less edge casey over time. |
| 02:23 | <shu> | ljharb: that's possible, and for that i pin hopes on implementation notes like for the memory model as we talked about |
| 02:24 | <jorendorff> | another footgun issue |
| 02:25 | <shu> | all host hooks are footguns, we can treat hosts as adversaries or as partners with some degree of trust |
| 02:25 | <jorendorff> | I didn't mean the host hook, I meant the issue of whether JSON modules should be immutable |
| 02:25 | <jorendorff> | I don't know |
| 02:26 | <shu> | ah |
| 02:26 | <jorendorff> | on the web, if you want mutability, you can just fetch() |
| 02:27 | <ljharb> | jorendorff: and if you want immutability, you could just Object.freeze it the first time you import it :-p |
| 02:33 | <akirose> | i think it was good to come back to this point and spell it out |
| 02:34 | <rickbutton> | ljharb: unless someone imports it first and changes it before you |
| 02:35 | <ljharb> | rickbutton: well sure, you can't defend against anything if you're not first-run code |
| 02:35 | <rickbutton> | true |
| 02:35 | <ljharb> | rickbutton: pretty sure if you're unable to safely run SES, then "is a json import mutable" isn't really your biggest problem |
| 02:35 | <rickbutton> | well, unless it is strictly immutable |
| 02:35 | <ljharb> | true :-) |
| 02:36 | <rickbutton> | do people actually want the ability to import a JSON module and change it? feels "icky" |
| 02:37 | <devsnek> | importing json is already kind of broken |
| 02:37 | <devsnek> | ez leaks |
| 02:37 | <haxjs> | what leak mean? |
| 02:37 | <devsnek> | haxjs: leaking memory |
| 02:38 | <haxjs> | oh, I agree! |
| 02:40 | <devsnek> | littledan: fwiw i think shared global namespace, in hindsight, was not a fantastic idea and i don't think we should create more of that |
| 02:40 | <rkirsling> | I agree with what jorendorff is saying |
| 02:41 | <littledan> | devsnek: I just think it's really important, pragmatically, in this case, that both TC39 and hosts can define assertions |
| 02:41 | <devsnek> | maybe `#type` |
| 02:41 | <littledan> | ? |
| 02:41 | <devsnek> | not a valid identifier |
| 02:42 | <devsnek> | separate namespace |
| 02:42 | <haxjs> | what #type mean? |
| 02:42 | <ljharb> | just a string with a hash in front? |
| 02:42 | <devsnek> | like if we reserved `#` things for tc39 |
| 02:42 | <devsnek> | forbidden extension to define your own |
| 02:42 | <jorendorff> | haha re: bikeshed-ability |
| 02:43 | <haxjs> | It seems `#` already used by several proposals? |
| 02:43 | <shu> | devsnek: i am not understanding, `type` isn't closed off as a key to hosts |
| 02:43 | <shu> | just the specific pair `type: 'json'` |
| 02:43 | <devsnek> | one value of it is |
| 02:43 | <shu> | and why is that so bad? |
| 02:43 | <devsnek> | for example if i wanted to use `type` for something meaningful to my host that isn't the format of the imported module |
| 02:44 | <devsnek> | it would definitely not be a good api for it to interfere with `type: json` |
| 02:45 | <ljharb> | why is it prohibitive for you to use an alternate name? |
| 02:45 | <devsnek> | because the name "type" might already be meaningful? |
| 02:45 | <devsnek> | this comes up in rust a lot where people use `kind` instead of `type` because `type` is a reserved keyword |
| 02:45 | <shu> | i see no difference between that and general namespace clashes |
| 02:45 | <shu> | it's so easy to feel strongly about the theoretical badness of namespace clashes |
| 02:45 | <devsnek> | shu: i think general namespace clashes are bad and we should not make new ones |
| 02:45 | <devsnek> | that's my point |
| 02:45 | <shu> | i do not see them as a problem borne out in practice |
| 02:45 | <jorendorff> | Hmm. this is a stronger point |
| 02:46 | <rickbutton> | HTML and TC39 regularly cooperate to share the global object namespace |
| 02:46 | <devsnek> | but if we did js again from scratch i assume that wouldn't be something we do |
| 02:47 | <shu> | we don't have that luxury, and thus in general i don't find appeals to "if we could rewind time" persuasive |
| 02:47 | <devsnek> | right but we don't have to rewind time |
| 02:47 | <devsnek> | this is a new feature |
| 02:48 | <devsnek> | are you saying shared namespaces are now idiomatic? |
| 02:48 | <shu> | so for your constraint i agree we don't have to rewind time |
| 02:48 | <shu> | i am, yes, but you're right that your view point was that it isn't |
| 02:48 | <shu> | oh whoa irccloud sent it out of order |
| 02:48 | <devsnek> | O.o |
| 02:50 | <devsnek> | i just know from experience with languages that claim certain identifiers that it is very annoying |
| 02:50 | <devsnek> | even if it doesn't come up every minute |
| 02:51 | <ljharb> | how is that avoidable tho without making either "making identifiers" or "using builtin things" less aesthetic? |
| 02:51 | <devsnek> | i don't see the need for this assertion to be part of the spec |
| 02:51 | <ljharb> | wait, so are we on a break rn or are we waiting for someone to fill the last 8-9min? |
| 02:51 | <drousso> | ^ +1 |
| 02:51 | <drousso> | would love to make dinner |
| 02:51 | <shrutikapoor> | not on a break yet |
| 02:51 | <rickbutton> | waiting for PFC to get ready |
| 02:51 | <shrutikapoor> | "WE WERE ON A BREAK" |
| 02:52 | <devsnek> | good break everyone |
| 02:52 | <shu> | shrutikapoor: oh i get that reference now |
| 02:52 | <devsnek> | terrible reference |
| 02:52 | <rkirsling> | what's the reference? |
| 02:52 | <devsnek> | f.r.i.e.n.d.s |
| 02:52 | <shu> | shrutikapoor: i grew up with seinfeld and it wasn't until like a month ago that my wife made me watch all of friends now that it's on streaming |
| 02:52 | <shrutikapoor> | lol |
| 02:53 | <rkirsling> | it's really hard to watch for the first time now |
| 02:53 | <shu> | friends? how come? |
| 02:53 | <rkirsling> | it's _painfully_ 90's if you don't have nostalgia goggles |
| 02:53 | <shu> | oh ha, yes, that part's true |
| 02:54 | <rkirsling> | I watched a season and a half a while back, should probably continue |
| 02:54 | <rickbutton> | fraiser holds up pretty well, modulo kelsey grammar |
| 02:54 | <rkirsling> | also sorry, we should probably move to tdz |
| 02:54 | <devsnek> | advance q plz |
| 02:55 | <ljharb> | MylesBorins akirose ^ |
| 02:55 | <MylesBorins> | which item are we on now again? |
| 02:55 | <ljharb> | GetOption |
| 02:55 | <jorendorff> | bears |
| 02:56 | <ljharb> | i'm still not seeing the slides ftr |
| 02:57 | <rickbutton> | io |
| 02:57 | <rickbutton> | i'm seeing them, on your end i tihnk |
| 02:57 | <ljharb> | i'm seeing istvan's placeholder pinned |
| 02:57 | <ljharb> | and there's no way to alter it |
| 02:58 | <ljharb> | oh hey there it goes |
| 03:01 | <shrutikapoor> | @rkirsling: Whats a tdz? |
| 03:01 | <akirose> | #temporaldeadzone |
| 03:01 | <rkirsling> | shrutikapoor: #temporaldeadzone, where all of our not-serious conversations happen :D |
| 03:01 | <akirose> | shrutikapoor: that's where the sass happens |
| 03:01 | <rkirsling> | ;) |
| 03:02 | <shrutikapoor> | thanks lol |
| 03:02 | <ljharb> | sass, but not LESS |
| 03:02 | <rkirsling> | true |
| 03:02 | <shrutikapoor> | SASS > LESS |
| 03:03 | <rickbutton> | less < more |
| 03:05 | <akirose> | HEY EVERYONE |
| 03:05 | <akirose> | does anyone have a 30-ish minute timebox they want to tackle after lunch? |
| 03:05 | <akirose> | we have an open slot at the end of the day |
| 03:06 | <haxjs> | my proposal-deiter is 15 mins. Is that ok? |
| 03:07 | <akirose> | haxjs: if you can find another 15 min to team up with |
| 03:08 | <haxjs> | maybe Chengzong Wu's topic? I will ask him |
| 03:12 | <rbuckton> | rkirsling: I wrote down a very brief sketch about some helpful string APIs for either `String.prototype` or `Intl` if you're interested: https://gist.github.com/rbuckton/cc14f0ff97cf420f474996fee2f78a13 |
| 03:12 | <rkirsling> | it seems like a good problem space |
| 03:13 | <devsnek> | is there a part of unicode for saying like |
| 03:13 | <devsnek> | `a` is latin, `м` is cyrillic, `η` is greek, etc |
| 03:13 | <devsnek> | it doesn't have to be latin/cyrillic/greek but understanding that those characters are part of different sets |
| 03:14 | <rbuckton> | Rather than clutter `String.prototype`, I moved most of the design to an `Intl.StringInfo` namespace (though it can be called whatever), but I did put `.codePointCount()` and `.nthCodePoint(n)` on `String.prototype` because there's already a few code-point related APIs on `String`, so they feel somewhat more natural there. |
| 03:14 | <haxjs> | devsnek: can use regexp to test it, but i agree methods are much easy to use |
| 03:15 | <devsnek> | haxjs: you mean like `\p{Latin_Letter}` or whatever? |
| 03:15 | <haxjs> | yes |
| 03:15 | <devsnek> | yeah that's like the reverse of what i'm thinking of |
| 03:15 | <devsnek> | rbuckton: is that "unicode category" in your gist? |
| 03:16 | <rbuckton> | haxjs: Yeah, most of these methods are already in the spec since they need to exist for `RegExp` evaluation, but testing for them requires using a `RegExp` which can be expensive. |
| 03:17 | <rbuckton> | devsnek: no, I don't think so. |
| 03:19 | <akirose> | okay i have a taker on the 30 min slot |
| 03:21 | <devsnek> | i can rant for 30 minutes about hashing apis |
| 03:22 | <rbuckton> | Hashing? |
| 03:22 | <devsnek> | hashing values |
| 03:22 | <rbuckton> | cryptographic hashing or hashcodes for identity/equality purposes? |
| 03:22 | <devsnek> | oh the latter |
| 03:23 | <rbuckton> | I've been thinking about that too. |
| 04:01 | <michaelficarra> | devsnek: you're looking for scripts |
| 04:01 | <devsnek> | michaelficarra: hm? |
| 04:01 | <devsnek> | oh for the categorization |
| 04:01 | <devsnek> | i assume no way to query that from js |
| 04:01 | <michaelficarra> | sure there is, just in RegExps |
| 04:03 | <haxjs> | already start? |
| 04:03 | <robpalme> | yes |
| 04:04 | <michaelficarra> | devsnek: /^\p{Script=Greek}$/u.test('ρ') |
| 04:04 | <devsnek> | michaelficarra: nothing O(1) :P |
| 04:04 | <devsnek> | have to iterate over tens of regexes |
| 04:05 | <michaelficarra> | sure, there's no API that gives you a character's script |
| 04:05 | <michaelficarra> | or any other Unicode property, to my knowledge |
| 04:06 | <ljharb> | could you make a single regex listing each of the scripts as a (named?) capturing group, and use .match to see which ones it matched? |
| 04:07 | <rickbutton> | the regex engine would iterate over each of those groups to see which one matched |
| 04:07 | <rickbutton> | would it not? |
| 04:07 | <devsnek> | faster than calling exec on each one |
| 04:07 | <rickbutton> | true |
| 04:08 | <devsnek> | i wonder if the unicode crates could help with this |
| 04:08 | <devsnek> | can we just add `Intl.CLDR` constants |
| 04:08 | <rickbutton> | are there ecosystem solutions? I imagine they just build a big object map from char->script |
| 04:08 | <devsnek> | yeah i think you could use data from the unicode crate to generate a map |
| 04:08 | <devsnek> | a large map |
| 04:08 | <rbuckton> | Write a script that uses RegExps to generate a script containing a function that takes in a codePoint and returns the script based on the value of the codepoint? |
| 04:09 | <michaelficarra> | we don't even have a titlecase operation on strings, asking for arbitrary Unicode property access is a bit of a stretch |
| 04:09 | <devsnek> | it can be on intl |
| 04:09 | <shu> | just a bag of... all units? |
| 04:10 | <devsnek> | `Intl.generalCategoryOf(c)` |
| 04:10 | <michaelficarra> | shu: yeah I can't imagine the use cases |
| 04:10 | <devsnek> | i wanted to make a thing to detect when people do stuff like "мıηαтσ" |
| 04:10 | <devsnek> | for moderation purposes |
| 04:11 | <rbuckton> | devsnek: that's kind of like what I was talking about in https://gist.github.com/rbuckton/cc14f0ff97cf420f474996fee2f78a13 |
| 04:11 | <rkirsling> | devsnek: I mean presumably not so far as to try to resolve σ to o though, right? |
| 04:11 | <michaelficarra> | devsnek: there's a few concepts you should be familiar with, let me get you the links |
| 04:11 | <devsnek> | rkirsling: no i don't want to normalize |
| 04:11 | <devsnek> | the normalization there would basically be OCR |
| 04:12 | <rkirsling> | right |
| 04:12 | <rkirsling> | just makin' sure |
| 04:12 | <devsnek> | different categories in the same string is a good indicator of someone doing that |
| 04:12 | <devsnek> | then you normalize it to "dumb nickname" |
| 04:13 | <michaelficarra> | devsnek: Unicode contains information on "confusables": http://www.unicode.org/reports/tr39/ |
| 04:14 | <rickbutton> | neatr |
| 04:14 | <devsnek> | oh wow |
| 04:14 | <rickbutton> | *neat |
| 04:14 | <michaelficarra> | also, there is a concept called "mixed script" (http://www.unicode.org/reports/tr39/#Mixed_Script_Detection) which browsers use when displaying IDNs (or their punycode) |
| 04:14 | <michaelficarra> | so if it's mixed-script, it's suspect |
| 04:15 | <devsnek> | oh wow `# ( М → M ) CYRILLIC CAPITAL LETTER EM → LATIN CAPITAL LETTER M #` |
| 04:15 | <michaelficarra> | people have used this data to make cool confusable string generators: https://www.irongeek.com/homoglyph-attack-generator.php |
| 04:15 | <rkirsling> | fascinating |
| 04:16 | <michaelficarra> | devsnek: yeah, there's a few Cyrillic characters that use the exact same glyph as their Latin counterparts |
| 04:16 | <devsnek> | not in the unicode package though |
| 04:16 | <devsnek> | might pr that |
| 04:18 | <michaelficarra> | I implemented confusables stuff for PureScript (which is interoperable with JS): https://github.com/michaelficarra/purescript-confusables |
| 04:19 | <devsnek> | ohnopurescript |
| 04:20 | <rkirsling> | TIL Hanb |
| 04:20 | <rkirsling> | does that subsume Hans or Hant or both? |
| 04:21 | <michaelficarra> | Hanb is "Han with Bopomofo", I don't know much beyond that |
| 04:21 | <rkirsling> | (seems like both, i.e. Hani, which I didn't know either) |
| 04:24 | <devsnek> | sent confusables.txt to friend at discord who did mention completion/user search |
| 04:28 | <rkirsling> | was that a casual Fiddler reference |
| 04:28 | <michaelficarra> | more people should know about Unicode confusables |
| 04:29 | <robpalme> | rkirsling: Dan spent a long time considering % of audience who would clock that joke ;-) |
| 04:29 | <michaelficarra> | devsnek: they should also strip diacritics and case fold |
| 04:30 | <devsnek> | michaelficarra: yeah they already do some stuff |
| 04:30 | <devsnek> | i put them on the trail of S.p.normalize a few months ago |
| 04:30 | <rkirsling> | robpalme: nice |
| 04:39 | <littledan> | can someone click forward on the queue so that it's possible to respond? |
| 04:39 | <rickbutton> | they did you can respond |
| 04:42 | <devsnek> | brad4d: they can be used in sets/maps, but not weak sets/maps |
| 04:44 | <littledan> | akirose: I'm not sure which reply you're referring to |
| 04:54 | <littledan> | agree that these are good things to think about; disagree with "must" framing |
| 04:55 | <ljharb> | littledan: everybody has their own "must"s, to me this is a must. |
| 04:55 | <devsnek> | i feel like people get too caught up in object/primitive categorization |
| 04:55 | <littledan> | ljharb: I don't think this is a productive framing |
| 04:55 | <ljharb> | it's ok that we disagree on the productivity of the framing. |
| 04:56 | <littledan> | well, I think this is a real problem in the committee, as framing goals as "must" can shut down conversations where we could learn more |
| 04:56 | <littledan> | "you must not frame things this way" there |
| 04:56 | <littledan> | now what happens? |
| 04:56 | <ljharb> | that sounds like you're suggesting any hard constraints shut down discussion |
| 04:57 | <ljharb> | what happens is that constraints apply to spec changes, not to discussion |
| 04:57 | <ljharb> | so i'm allowed to apply "must"s to proposals, nobody's allowed to apply them to discussion. |
| 04:57 | <ljharb> | s/i'm/everybody is |
| 04:58 | <littledan> | sorry, it was a distracting joke |
| 04:58 | <Bakkot> | "allowed" is also kind of a bad framing |
| 04:58 | <devsnek> | i feel like people get too caught up in object/primitive categorization |
| 04:59 | <ljharb> | Bakkot: fair |
| 04:59 | <shu> | ljharb: i think you're misunderstanding identity as a property of "object" or "primitive". identity is a property of "encapsulated structure" |
| 05:00 | <ljharb> | pre-es6, the two overlapped. symbols changed that a bit |
| 05:00 | <shu> | it so happens there's a primitive/object divide, but that's not the reason for why things have identity |
| 05:00 | <devsnek> | symbols, depending on how you view them, are one example of that |
| 05:00 | <akirose> | rbuckton: you're up |
| 05:01 | <rbuckton> | yep |
| 05:02 | <akirose> | ystartsev_: you're on deck |
| 05:02 | <ystartsev_> | for process? |
| 05:02 | <ystartsev_> | got it |
| 05:02 | <ljharb> | shu: what is the reason? |
| 05:02 | <ystartsev_> | shu: is your concern re: the primitives version of the proposal? |
| 05:02 | <devsnek> | because of their inherent encapsulated structure :P |
| 05:03 | <ljharb> | devsnek: what are symbols' encapsulated structure? |
| 05:03 | <devsnek> | same as a frozen object |
| 05:03 | <shu> | ystartsev_: i have no concern about the path of investigation, i was just responding to jordan |
| 05:03 | <devsnek> | they're a unique thing |
| 05:04 | <ljharb> | devsnek: how is "unique" a property of strucutre? |
| 05:04 | <ljharb> | *structure |
| 05:05 | <shu> | ljharb: actually how do Symbols have identity? you're talking about `Symbol() !== Symbol()`? |
| 05:05 | <shu> | like, the gensym case? |
| 05:05 | <michaelficarra> | so when is the next opportunity to reconsider our 4 short days and possibly go back to 3 longer days? |
| 05:05 | <ljharb> | shu: yes, it's the only primitive where you can duplicate the source text, but the result isn't `===` |
| 05:05 | <michaelficarra> | or are we stuck with 4 days forever now? |
| 05:06 | <devsnek> | i prefer four days when the time goes to 1am |
| 05:06 | <msaboff> | michaelficarra What don't you like about 4 days 5 hours each day? |
| 05:06 | <shu> | ljharb: my mental model is that Symbols still don't have identity, because what `Symbol()` does is to generate a new unique Symbol, not be a unit value like e.g. Number() |
| 05:07 | <rkirsling> | I am interested in the idea of scattering topics across timezones |
| 05:07 | <Bakkot> | msaboff I dislike the four day schedule because I basically don't get work done for four days now, instead of three |
| 05:07 | <michaelficarra> | msaboff: it's effectively 1/3 longer meetings |
| 05:07 | <ljharb> | shu: it's the only primitive that works that way tho |
| 05:07 | <msaboff> | Got it |
| 05:07 | <devsnek> | ljharb: depends on your definition of primitive |
| 05:07 | <shu> | ljharb: but since Symbol.for("foo") === Symbol.for("foo"), i don't consider it having identity |
| 05:07 | <ljharb> | devsnek: what's yours? |
| 05:08 | <Bakkot> | also, wrt the november meeting, I think I'd prefer three nights of being up almost all night over four nights of being up all night |
| 05:08 | <rickbutton> | it depends on what the definition if "is" is |
| 05:08 | <Bakkot> | but that might not be true; we'll see when it happens |
| 05:08 | <ljharb> | shu: that's just because global symbols are different - ie, memoized in a cross-realm registry |
| 05:08 | <michaelficarra> | I'd even prefer 4 longer days over 4 shorter days, just so that my time isn't going to waste |
| 05:08 | <devsnek> | ljharb: everything listed in "ECMAScript Language Types" |
| 05:08 | <ljharb> | Bakkot: +1 to that one |
| 05:08 | <rickbutton> | ^ but really, do we have a formal definition of "identity" or it is just inherent from the definition of an object? |
| 05:08 | <msaboff> | Bakkot I agree that 3 days is preferably for the Nov meeting. |
| 05:08 | <shu> | ljharb: that's not "just because", that's the semantics |
| 05:08 | <jridgewell> | Shu, thats like saying `o = {}, o === o` means objects don't have identity. |
| 05:08 | <ljharb> | rickbutton: imo "identity" is "if you repeat the source text twice, the two results are !==" |
| 05:08 | <rickbutton> | that is not the way I think about identity |
| 05:08 | <devsnek> | jridgewell: there is some argument about how Symbol.for is described |
| 05:09 | <devsnek> | jridgewell: some people don't think of it in terms of a global map |
| 05:09 | <ljharb> | shu: well sure, but symbols still have identity - it's just that Symbol.for memoizes that identity-having symbol |
| 05:09 | <shu> | jridgewell: no, identity is always reflexiv? |
| 05:09 | <Bakkot> | the word "identity" is doing more harm than good here |
| 05:09 | <rkirsling> | ^ |
| 05:09 | <Bakkot> | we should have this debate without using it |
| 05:09 | <rkirsling> | it's a weird word for this I think |
| 05:09 | <michaelficarra> | ljharb: NaN |
| 05:09 | <rkirsling> | we're talking about definitional equality, yeah? |
| 05:09 | <ljharb> | michaelficarra: fair |
| 05:09 | <ljharb> | what term would you use "symbols and objects" versus "non-symbol primitives"? |
| 05:09 | <ljharb> | *use for |
| 05:09 | <ljharb> | michaelficarra: NaN is definitely the oddball |
| 05:10 | <rickbutton> | * non-Symbol.for symbols and objects vs "the rest" |
| 05:10 | <ystartsev_> | +1 to Bakkot |
| 05:10 | <Bakkot> | the way I would put it is that strings and numbers compare by their contents, objects and symbols do not |
| 05:10 | <ljharb> | michaelficarra: but i could tweak my definition to be `!Object.is()` instead of !== and it'd hold |
| 05:10 | <shu> | when i say identity, i mean the thing that values that do not compare by contents use to compare |
| 05:10 | <ljharb> | also booleans and null and undefined and bigints? |
| 05:10 | <shu> | that is the essence of identity |
| 05:10 | <ystartsev_> | yep, and that is the same mechanism we would see at work here |
| 05:10 | <shu> | if you compare by contents, you do not have identity |
| 05:10 | <ljharb> | shu: i agree with that |
| 05:10 | <Bakkot> | ljharb right, those things compare by contents |
| 05:11 | <ljharb> | Bakkot: and Symbol.for symbols? |
| 05:11 | <shu> | and my mental of Symbols is that they compare by content; it happens it's "implemented" in the spec by a cross-realm registry |
| 05:11 | <rickbutton> | ^ this is also my mental model |
| 05:11 | <ljharb> | hmm |
| 05:11 | <ljharb> | what is the content of a symbol? |
| 05:11 | <rickbutton> | we just use the word identity as a shortcut |
| 05:11 | <devsnek> | my mental of symbols is identical to objects |
| 05:12 | <shu> | ljharb: for symbols resulting from Symbol.for, the string content, otherwise, just some sui generis thing |
| 05:12 | <ljharb> | i would very much disagree with the claim that symbols are compared by contents, they have no contents |
| 05:12 | <Bakkot> | yeah what shu said |
| 05:12 | <ljharb> | i didn't give it anything to contain |
| 05:12 | <shu> | you do... |
| 05:12 | <devsnek> | Symbol.for symbols contain a string |
| 05:12 | <rickbutton> | an empty string has contents |
| 05:12 | <rkirsling> | a private string |
| 05:12 | <Bakkot> | that's ok, 0 doesn't contain anything either but like |
| 05:12 | <ljharb> | Symbol('') !== Symbol(''), so the string isn't the contents it's comparing |
| 05:12 | <devsnek> | maybe they have a hidden number, a pointer for example |
| 05:13 | <devsnek> | :^) |
| 05:13 | <jridgewell> | And `Symbol.for('foo') !== Symbol('foo')` |
| 05:13 | <ljharb> | obv you can do mental gymnastics to make any mental model work, but i can't observe or provide that hidden number |
| 05:13 | <shu> | that's because the "description" isn't the contents? |
| 05:13 | <shu> | idk man, y'all have a lot of adherence to surface structure |
| 05:13 | <devsnek> | i don't get describing symbols differently from objects |
| 05:13 | <ljharb> | symbols are the same as objects. they don't compare by contents. |
| 05:13 | <ljharb> | they compare by "bakkot's forbidden term" |
| 05:13 | <devsnek> | i mean i understand it |
| 05:14 | <devsnek> | but i don't get why you would prefer that model to whatever your model is for objects |
| 05:14 | <rickbutton> | the spec uses the wording "the same value" when it needs to compare objects or symbols |
| 05:14 | <rickbutton> | for what it is worth |
| 05:15 | <littledan> | btw if people have concerns about an all-Igalia review team, then I encourage you to sign on or recruit a third reviewer |
| 05:15 | <rkirsling> | rbuckton: I like how you just *apologized* for being efficient with your time |
| 05:15 | <michaelficarra> | I hope we're not expected to have read this yet |
| 05:15 | <michaelficarra> | I never ended up reading it because there was still so much churn and back-and-forth in the PR |
| 05:16 | <rkirsling> | same |
| 05:16 | <rbuckton> | ;) |
| 05:16 | <devsnek> | can we put a requirement on all our official documents to have `max-width: 60em` |
| 05:16 | <rkirsling> | I was gonna wait until the battling died down |
| 05:19 | <michaelficarra> | … so are we never going to revisit 3 days vs 4 days? |
| 05:19 | <ljharb> | michaelficarra: probably best to file a reflector issue |
| 05:20 | <michaelficarra> | I was just wondering if we scheduled a date to revisit, but I guess we've made it permanent? |
| 05:20 | <ljharb> | i don't think it's permanent, the january meeting doesn't have a timezone picked yet afaik? |
| 05:20 | <rkirsling> | not so much permanent as like, we had inertia for one thing and now we have inertia on another thing |
| 05:21 | <michaelficarra> | I agree so much about the inability of taking the temperature of the room |
| 05:21 | <devsnek> | isn't that kind of antithetical to consensus, e.g. the goal is "is this unworkable" not "does everyone like this" |
| 05:21 | <michaelficarra> | someone must have solved this problem with software |
| 05:22 | <michaelficarra> | devnsek: it's still informative if we're about to advance something that most people have weak reservations about |
| 05:22 | <rkirsling> | michaelficarra: I think it may be that our process has been too dependent on a physical room |
| 05:22 | <michaelficarra> | *devsnek |
| 05:23 | <Bakkot> | fwiw I am always excited about the intl proposals |
| 05:23 | <devsnek> | intl is very cool |
| 05:23 | <littledan> | me too |
| 05:23 | <michaelficarra> | Intl basically can do no wrong in my book |
| 05:24 | <Bakkot> | I don't talk about them because a.) I don't know enough about the space to have opinions and b.) they basically all look good |
| 05:24 | <littledan> | What if we required an explicit "second" and "third" for proposal advancements? |
| 05:24 | <ljharb> | +1 |
| 05:24 | <littledan> | like two non-champions voicing explicit support |
| 05:24 | <ljharb> | (to Bakkot) |
| 05:24 | <ljharb> | but actually i like littledan's idea too |
| 05:24 | <littledan> | :) |
| 05:24 | <ljharb> | not requiring unanimous enthusiastic consensus, but requiring more than one person being enthusiastic |
| 05:24 | <littledan> | (I would like to get a more broad view of the room, too; 2nd/3rd seems like a minimum) |
| 05:25 | <ljharb> | and theoretically should be super easy on a good proposal |
| 05:25 | <rkirsling> | littledan: I like it |
| 05:25 | <rickbutton> | not opposed, but it would be weird if it ended up being the same set of people voicing a +1 for consensus for every proposal |
| 05:26 | <rickbutton> | in the same way that some people talk more than others (not a bad thing, but an observation) |
| 05:26 | <rkirsling> | hmmmm |
| 05:26 | <Bakkot> | <devsnek hat> discord has emoji reactions for this situation! </devsnek hat> |
| 05:26 | <rkirsling> | loool. it's true though. |
| 05:26 | <Bakkot> | (that is a feature of discord I quite like) |
| 05:26 | <rickbutton> | 🚀 we also have emojis in discord |
| 05:26 | <rickbutton> | *irc |
| 05:27 | <devsnek> | i appreciate devsnek hat |
| 05:27 | <michaelficarra> | I want like a happiness slider that averages all of our individual happiness sliders |
| 05:27 | <rkirsling> | ^ nice |
| 05:27 | <rickbutton> | michaelficarra: its 2020 lets not quantify our happiness |
| 05:27 | <littledan> | I like the emoji reacts idea too |
| 05:27 | <michaelficarra> | rickbutton: it doesn't have to apply outside a 30 second window |
| 05:27 | <rkirsling> | I agree with the current point in that I would have a really hard time being a sole objector on just about anything, given my personality |
| 05:27 | <littledan> | we could also literally just paste our emojis in IRC |
| 05:27 | <Bakkot> | true, but discord reacts are a lot... easier... somehow? |
| 05:28 | <Bakkot> | they feel less like an interjection and more like smiling |
| 05:28 | <devsnek> | everyone steps into a booth where they must win an argument with mark about the feature being at least as good as the equivalent in elang. if every member can do so, the feature passes |
| 05:28 | <littledan> | yeah they are |
| 05:28 | <rickbutton> | you can click an emoji that someone else already used, is the nice thing |
| 05:28 | <littledan> | (Matrix has emoji reacts also...) |
| 05:28 | <shu> | michaelficarra: Intl can do no wrong? |
| 05:28 | <devsnek> | did you know in discord you can type `+:emoji:` to react to the last message |
| 05:28 | <shu> | michaelficarra: what about `Intl.stringRepresentation = 'ebcdic'` |
| 05:29 | <rkirsling> | devsnek: or slack |
| 05:29 | <michaelficarra> | I am currently feeling (polar bear) about this proposal |
| 05:29 | <shu> | what does polar bear mean |
| 05:29 | <rickbutton> | if we are going full -live reactons- lets just get an audience clap meter set up |
| 05:29 | <shu> | ravenous? |
| 05:29 | <michaelficarra> | rickbutton: yes! |
| 05:30 | <devsnek> | the real reason -0 is important |
| 05:30 | <rkirsling> | live temp gauge |
| 05:30 | <rkirsling> | in TCQ |
| 05:30 | <rkirsling> | let's do this |
| 05:30 | <shu> | ljharb: given how against voting you are this seems like voting? |
| 05:30 | <ljharb> | shu: i definitely don't want voting, but i do want a way to measure the room |
| 05:30 | <rickbutton> | unfortunately you don't get to put a minus sign next to your ballot choice |
| 05:30 | <devsnek> | if you measure the room and no one likes it |
| 05:30 | <shu> | (not that i'm against that, i kinda like wasm's voting by a scale of "strongly against" to "strongly for") |
| 05:30 | <devsnek> | but no one objects |
| 05:30 | <ljharb> | shu: iow, a "-0" wouldn't block advancement, but it might encourage others to speak up about their own -0's |
| 05:31 | <ljharb> | shu: i think that if 90% of the room is -0, that's severely important information to surface |
| 05:31 | <littledan> | 🐸 |
| 05:31 | <ljharb> | let the record show that dan is "frog" on this proposal |
| 05:31 | <shu> | ljharb: well, okay, in practice having a quantified temperature measure approaches voting in practice IME |
| 05:31 | <shu> | you can skirt around the formality of it |
| 05:32 | <ljharb> | shu: i think a "yes/no/abstain" is voting. I think having the "neutral, but negative/neutral, but positive" options drastically changes the dynamics |
| 05:32 | <littledan> | I think it's pretty different; it leaves room for judgement calls |
| 05:32 | <ljharb> | ^ that |
| 05:32 | <devsnek> | if everyone feels meh about it, even though no one objects, that may drive the champion to pull it for a future meeting |
| 05:32 | <devsnek> | not an official vote |
| 05:32 | <devsnek> | but the effect of one |
| 05:32 | <ljharb> | but more importantly it signals to those in the room that might not otherwise be emboldened to endorse or objects |
| 05:32 | <shu> | why is that not a vote? |
| 05:32 | <ljharb> | *object |
| 05:32 | <shu> | other than you didn't call it a vote? |
| 05:32 | <ljharb> | shu: because if 90% of the room is -0, someone might decide to be -1 |
| 05:32 | <littledan> | well, in particular, it'd be very weird to play vote counting schemes in that world |
| 05:32 | <ljharb> | shu: if nobody decides to be -1, it can advance |
| 05:32 | <littledan> | that's one concrete concern |
| 05:33 | <shu> | ljharb: that is a voting system to me |
| 05:33 | <littledan> | it also does not put "outvoting someone" on the table |
| 05:33 | <ljharb> | hm |
| 05:33 | <shu> | but i think i'm missing something |
| 05:33 | <Bakkot> | a single -1 feels like it should not block |
| 05:33 | <ljharb> | shu: in what way is that different than the current consensus process? |
| 05:33 | <Bakkot> | I was -1 on .item |
| 05:33 | <Bakkot> | S.p.item, that is |
| 05:33 | <shu> | ljharb: the current one is not quantified and tallied across all delegates on tcq |
| 05:33 | <shu> | which is what i thought you were proposing |
| 05:33 | <devsnek> | Bakkot: but you're +1 on S.p.item |
| 05:33 | <littledan> | this is a way to add a bunch of opinion-gathering *within* our consensus system |
| 05:33 | <rkirsling> | interesting: https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions |
| 05:33 | <ystartsev_> | I feel like the scale should only be about temperature, blocking should still work as it is |
| 05:33 | <littledan> | I think that's very useful |
| 05:33 | <ljharb> | Bakkot: blocking would be -1, nonblocking icky would be -0, and by not blocking imo you'd be -0 in this system |
| 05:33 | <ljharb> | ystartsev_: agreed |
| 05:33 | <Bakkot> | ljharb that seems like not enough gradiation |
| 05:34 | <ljharb> | shu: i'm not talking about documenting the tallies |
| 05:34 | <littledan> | Bakkot: +🐸 |
| 05:34 | <Bakkot> | there is lots of stuff that I feel like "I don't think this is worth adding" |
| 05:34 | <ljharb> | Bakkot: no opinion on that, we can have a -10 to 10 scale as long as it's clear where the "block" threshold lives |
| 05:34 | <akirose> | Frank are you on IRC with a username that doesn't start with Frank? |
| 05:34 | <Bakkot> | S.p.item was "I feel like adding this with this semantics is actively harmful, but not enough to block" |
| 05:34 | <haxjs> | I think I would also -1 on .item because it seems we should use more time to discuss it :) but i don't want to block the whole proposal |
| 05:34 | <ystartsev_> | haxjs: thats an interesting take also -- just wanting to take more timee |
| 05:35 | <ljharb> | i think that would also have been reasonable to ask for (and it's in ystartsev_'s pr, iirc) |
| 05:35 | <ljharb> | but, only if "more time" is something that you could reasonably expect would change things |
| 05:35 | <rickbutton> | maybe the additional nuance around "non-blocking but icky" is useful (instead of simply -0) |
| 05:35 | <Bakkot> | I think "more time" often gives the rest of the committee a chance to form and express an opinion |
| 05:35 | <Bakkot> | even if it doesn't convince any of the major parties to the original discussion |
| 05:36 | <ljharb> | 👍 if that's likely, that's always a valid reason to delay imo |
| 05:36 | <ljharb> | (also fine to err on the side of delay, too) |
| 05:36 | <akirose> | whoever has synchronous contact with Frank please let him know i was able to get one of his overflow items on the schedule tomrrow |
| 05:36 | <haxjs> | as i stated before ,it have a big pressure to make decision in the meeting in very short time, u need to a big confidence that u understand all things everyone said. |
| 05:36 | <ljharb> | but not every champion has "shipping speed" in "not the top place" in the priority list. |
| 05:37 | <ljharb> | haxjs: hopefully 10 day review time, plus github discussion, helps with that, but you are also quite correct |
| 05:37 | <littledan> | I think "more time" is valid when it's valid, but there are also limits to these days. For example, I think two months is enough time to discuss whether there should be String.prototype.item and come to one conclusion or other. There are other decisions that may make sense to consider for longer amounts of time. |
| 05:37 | <littledan> | s/days/delays/ |
| 05:37 | <haxjs> | yeah, we have time to review , but sometimes there are many new input in the meeting. |
| 05:37 | <ljharb> | littledan: +1, haxjs: agreed |
| 05:37 | <littledan> | Right, so we have the agenda deadline; we could push that back, or be more strict about it |
| 05:38 | <ljharb> | we're pretty strict about it, things miss the deadline yet advance very rarely |
| 05:38 | <Bakkot> | things do come up in discussion, though |
| 05:38 | <Bakkot> | would be nice if we could more readily revisit discussions |
| 05:38 | <littledan> | there are some very large proposals that might take more than a week or two to review. For example, we agreed that Temporal should have at least a full meeting cycle between "stage 2 and frozen" and Stage 3 |
| 05:39 | <Bakkot> | honestly, I'd be in favor of dedicating the last day to revising stuff from the earlier ones |
| 05:39 | <haxjs> | Especially for non-native speakers we heavily rely on reading notes in difficult topics (for example, membrane :) |
| 05:39 | <Bakkot> | so that we could ask for a delay without that meaning several more months |
| 05:39 | <rickbutton> | that would be neat if it didn't cut into existing time for proposals |
| 05:39 | <shu> | Bakkot: i'd be supportive of that idea, yes, a half day even |
| 05:39 | <littledan> | membrane stuff is difficult for everyone, not just non-native speakers. There's a lot of background that we haven't clearly presented to the committee |
| 05:39 | <rkirsling> | ^ |
| 05:39 | <rkirsling> | membrane is the most difficult IMO |
| 05:39 | <Bakkot> | rickbutton I think it is worth it even if it does cut into existing time for proposals |
| 05:39 | <littledan> | ideally people can raise the review requests or requests for more information ahead of the meeting. |
| 05:40 | <littledan> | I mean, requests to have more review time |
| 05:40 | <littledan> | this could help champions provide the needed information |
| 05:40 | <Bakkot> | littledan things do come up in discussion, though |
| 05:40 | <devsnek> | you have not truly lived until you've seen a presentation on membranes |
| 05:40 | <littledan> | yes, for sure |
| 05:40 | <rickbutton> | Bakkot, certainly useful, but more useful? maybe |
| 05:40 | <rkirsling> | devsnek: steamy membranes? |
| 05:40 | <michaelficarra> | devsnek: in person, for the full effect |
| 05:40 | <littledan> | if something new comes up, that can be a good reason to think about things for longer, I agree |
| 05:40 | <Bakkot> | rickbutton let me put it a different way: I think it would have better outcomes for the language |
| 05:41 | <devsnek> | michaelficarra: the pacing is part of the presentation |
| 05:41 | <michaelficarra> | the high CO2 content is necessary |
| 05:41 | <devsnek> | lol |
| 05:41 | <rickbutton> | Bakkot fair |
| 05:41 | <Bakkot> | +1 mark |
| 05:42 | <rkirsling> | devsnek: lol that one is a fact |
| 05:42 | <devsnek> | i'm motivated by both mark's points and ron's points |
| 05:42 | <devsnek> | +0, if you like |
| 05:42 | <Bakkot> | I bought a CO2 meter to bring to meetings and then we stopped having meetings for which it was relevant |
| 05:42 | <littledan> | devsnek: Same |
| 05:43 | <rkirsling> | devsnek: ±0 even? |
| 05:43 | <rickbutton> | Bakkot: we have CO2 meters in all the Bloomberg meeting rooms, its a fun way to get out of a meeting by checking the meter and claiming that there is no way we are making good decisions any more |
| 05:44 | <akirose> | omg that time Brian brought one to TC39 at Google in New York |
| 05:44 | <rkirsling> | I am not familiar with this practice lol |
| 05:44 | <devsnek> | lmao |
| 05:45 | <Bakkot> | rickbutton incredible |
| 05:45 | <Bakkot> | I wonder if I get budget for that |
| 05:45 | <michaelficarra> | rickbutton: why add CO2 meters and not oxygen? |
| 05:45 | <Bakkot> | if there are ever offices |
| 05:45 | <rickbutton> | michaelficarra: it does both, they are embedded in the tables |
| 05:45 | <devsnek> | michaelficarra: why not windows |
| 05:45 | <michaelficarra> | devsnek: oxygen delivery holes? |
| 05:45 | <devsnek> | lol |
| 05:46 | <rickbutton> | no openable windows in the BB NY offices |
| 05:46 | <devsnek> | depends on how you consider openable |
| 05:46 | <devsnek> | 🔨 |
| 05:46 | <michaelficarra> | you mean they're not closeable |
| 05:47 | <devsnek> | mfw no tape emoji |
| 05:47 | <Bakkot> | 📼 |
| 05:48 | <devsnek> | https://i.kym-cdn.com/photos/images/facebook/000/909/991/48c.jpg |
| 05:48 | <Bakkot> | wait, this is the wrong channel, sorry |
| 05:48 | <michaelficarra> | pipobscure: new.target, they're called meta properties |
| 05:48 | <ljharb> | pipobscure: `super.foo`, as well |
| 05:48 | <devsnek> | `import.meta` |
| 05:49 | <michaelficarra> | hold up, have we already adopted the Apache voting? |
| 05:49 | <ystartsev_> | i think we are playing with it to see how it feels |
| 05:49 | <ljharb> | people are just saying numbers |
| 05:50 | <rkirsling> | -1 is full blocking though |
| 05:50 | <michaelficarra> | I am -e on this proposal |
| 05:50 | <ystartsev_> | rkirsling: i would disagree, blocking stays the same |
| 05:50 | <rkirsling> | if we do Apache-style |
| 05:50 | <devsnek> | -Number.EPSILON |
| 05:50 | <ljharb> | michaelficarra: that's over twice a block |
| 05:50 | <Bakkot> | don't think we should assign numbers to blocking |
| 05:50 | <Bakkot> | if you want to block you say so |
| 05:50 | <devsnek> | is small `e` epsilon |
| 05:50 | <rkirsling> | ah okay |
| 05:50 | <ystartsev_> | sorry my irc isn't really working |
| 05:50 | <michaelficarra> | ljharb: you're right, I should make it bigger |
| 05:50 | <Bakkot> | numbers are for expressing sentiment |
| 05:50 | <rkirsling> | that works for me |
| 05:50 | <ljharb> | too bad there's no Math.clamp |
| 05:50 | <devsnek> | or euler's number |
| 05:50 | <ljharb> | devsnek: E is epsilon, iirc? |
| 05:51 | <devsnek> | 🤷🏻 |
| 05:51 | <rkirsling> | euler's number |
| 05:51 | <michaelficarra> | > The number e, known as Euler's number, is a https://en.wikipedia.org/wiki/Mathematical_constant approximately equal to 2.71828 |
| 05:51 | <rkirsling> | Math.E vs. Number.EPSILON |
| 05:51 | <ljharb> | it's also Math.PI, so obv Math is just shouty |
| 05:51 | <Bakkot> | constants are all caps |
| 05:51 | <Bakkot> | traditionally |
| 05:52 | <ljharb> | Symbol.iterator? |
| 05:52 | <michaelficarra> | lol undefined.something |
| 05:52 | <michaelficarra> | (legal syntax) |
| 05:52 | <Bakkot> | what about symbol.iterator? |
| 05:52 | <devsnek> | Symbol.ITERATOR |
| 05:52 | <ljharb> | why not Symbol.ITERATOR |
| 05:52 | <ljharb> | it's a frozen property |
| 05:52 | <Bakkot> | that is not a constant in the sense in which π is a constant |
| 05:52 | <ljharb> | more constant than Math.PI, even |
| 05:52 | <ljharb> | how so? it's an unchangeable cross-realm value :-p |
| 05:53 | <devsnek> | i don't think of Symbol.iterator as a constant |
| 05:53 | <devsnek> | i'm not sure how to explain this intuition |
| 05:53 | <Bakkot> | π is a constant in the math sense |
| 05:53 | <rickbutton> | it doesn't go into .rodata |
| 05:53 | <Bakkot> | lol |
| 05:53 | <ljharb> | window.Infinity, then |
| 05:53 | <devsnek> | rickbutton: i have news for you |
| 05:53 | <rickbutton> | :) |
| 05:53 | <ljharb> | globalThis.Infinity, sorry |
| 05:53 | <ystartsev_> | rkirsling: sorry, to finish --> i think blocking should continue as is, with a reason |
| 05:53 | <Bakkot> | infinity I could see a case for |
| 05:53 | <ystartsev_> | gosh, why did irc have to poot out on me now |
| 05:54 | <ljharb> | also NaN, why not NAN |
| 05:54 | <gibson042> | Number.POSITIVE_INFINITY |
| 05:54 | <rkirsling> | ystartsev_: yeah Bakkot expressed similarly, that sounds good 👍 |
| 05:54 | <ljharb> | i stand by Math being shouty |
| 05:54 | <Bakkot> | NaN is just precedent from other languages |
| 05:54 | <rkirsling> | ystartsev_: I wasn't sure just how Apache-ish we were looking to go |
| 05:54 | <michaelficarra> | did Ron just withdraw this proposal? 🙏 |
| 05:54 | <ystartsev_> | yes, i think so |
| 05:54 | <ljharb> | wait what? i didn't hear that |
| 05:54 | <ljharb> | rbuckton: ? |
| 05:55 | <rkirsling> | I love that we're actually trying these numbers |
| 05:55 | <rkirsling> | no joke |
| 05:55 | <devsnek> | i've lowkey used them in the past |
| 05:55 | <michaelficarra> | rkirsling: I agree, it is already helping me |
| 05:55 | <rbuckton> | I didn't withdraw, but its under consideration. |
| 05:55 | <ystartsev_> | ah ok |
| 05:55 | <ljharb> | rbuckton: ty |
| 05:55 | <ystartsev_> | i do like the numbers, it feels nice to get a sense of where people are |
| 05:56 | <shu> | i do not fully understand what hax is arguing for, that we should reserve `class.` for future use cases? |
| 05:56 | <michaelficarra> | shu: yeah sounds like it |
| 05:56 | <devsnek> | i just got kicked out of tcq |
| 05:57 | <devsnek> | reloading fixed |
| 05:57 | <devsnek> | very odd |
| 05:57 | <shu> | michaelficarra: thx |
| 05:57 | <ljharb> | how would a decorator function, defined in another file, be able to use special syntax? |
| 05:58 | <michaelficarra> | I think this syntax space has the potential to be used for FAR more valuable proposals than this |
| 05:58 | <ljharb> | such as? |
| 05:58 | <ljharb> | (do you feel the same about `static.`?) |
| 05:58 | <rkirsling> | `static.` seems less bad |
| 05:59 | <ljharb> | so your concern isn't "this is a bad feature", it's "this syntax should be put to better use"? |
| 05:59 | <michaelficarra> | I would feel the same about just about any syntax, since I see this proposal as having just about zero value |
| 05:59 | <ljharb> | rbuckton: why wouldn't `class.#x` work? did i miss that slide |
| 05:59 | <michaelficarra> | ljharb: why not both? |
| 05:59 | <ljharb> | michaelficarra: noted |
| 06:00 | <rkirsling> | I think "papercut" is a good metaphor |
| 06:00 | <littledan> | haxjs: it's hard for me to understand which sense of metadata you want to be made especially available within the lexical scope of the class |
| 06:00 | <rkirsling> | one never _needs_ to use an anonymous class, right? |
| 06:00 | <rbuckton> | `static` could be a reserved identifier inside of a class, given that its currently restricted inside of a class... |
| 06:00 | <haxjs> | littledan: I just use decorator as example, if there is no usecase, i would think class.xxx is not worth. |
| 06:01 | <ljharb> | rkirsling: when decorating an anonymous class, one must produce one, if one wants to be unobservable |
| 06:01 | <littledan> | I like the idea of using static.foo for this, if we do add it |
| 06:01 | <michaelficarra> | rkirsling: nope: https://github.com/tc39/proposal-class-access-expressions/issues/13 |
| 06:01 | <rkirsling> | ljharb: oh that's where decorators come in. sorry, I didn't follow this particular thread |
| 06:01 | <haxjs> | yeah we have a addition that u can `new static` but not `new class` |
| 06:02 | <littledan> | haxjs: Oh, I see. Yeah, I could think of other cases for `class.` Another totally unrelated case is, if we really don't want to use [no LineTerminator here], then we could make value classes declared as `class.value C { }`, etc |
| 06:02 | <rbuckton> | IRCCloud keeps failing to send my messages. |
| 06:04 | <haxjs> | littledan: yeah `class.value C {}` is great example of keeping the syntax space. thank u! |
| 06:04 | <littledan> | or `class.typed`, etc |
| 06:05 | <haxjs> | it always make me think whether we can have a convention of use keyword.xxx for new keyword. like await.all . |
| 06:05 | <rbuckton> | Can't say I'm a fan of `class.value C {}`. That's using `.` in a completely different way than we've ever used it in the language. I'd rather see `value class C {}` or `struct C {}` than that. Except for numbers and regexp's, `.` should stay in the realm of property access |
| 06:06 | <haxjs> | rbuckton: The point is not every case we could have `xxx keyword` or `keyword xxx`. For example `await.all` case. |
| 06:06 | <akirose> | by the way THANK YOU SO MUCH NOTE TAKERS |
| 06:07 | <robpalme> | the note takers were great today. |
| 06:07 | <haxjs> | also `with suffix x = ...` many people don't like overload `with`, but i guess `const.suffix x = ...` could get more acceptence?? |
| 06:07 | <rbuckton> | Teams has a feature where you can use the auto captions to create a transcript of the meeting. I wonder if that would be helpful for notetaking? |
| 06:08 | <Bakkot> | re: notes: I am playing with hooking the google speech-to-text API up to google docs |
| 06:08 | <Bakkot> | turns out that API is super cheep |
| 06:08 | <Bakkot> | and then note takers would just need to fix its jank |
| 06:08 | <Bakkot> | not sure it will be good enough though |
| 06:09 | <michaelficarra> | worst case, we can try it in parallel and compare the results |
| 06:09 | <rkirsling> | post-editing is infinitely easier than writing so I would bet it'd be good enough |
| 06:09 | <rickbutton> | would love to trial it if you get it set up |
| 06:09 | <rbuckton> | The main thing I dislike about the transcription in Teams (at least, the last time I used it), is that it doesn't attribute the text to the speaker (which it seems like it should be able to do). |
| 06:09 | <littledan> | haxjs: yeah, I could see `const.suffix` but I do think that many people see the `.` as ugly in that sort of case. Anyway the objections were more about namespaces than the surface syntax |
| 06:09 | <haxjs> | rbuckton: can't find auto caption in the menu... |
| 06:09 | <shu> | good night all |
| 06:10 | <Bakkot> | my approach will not do attribution, so we'd need humans for that |
| 06:10 | <Bakkot> | rbuckton is the transcript live-editable, or just a document you download after the fact? |
| 06:10 | <rickbutton> | good night shu |
| 06:11 | <littledan> | Good morning everyone |
| 06:11 | <rickbutton> | lmao |
| 06:11 | <rbuckton> | It may be a preview feature (which requires opt-in in Settings): https://usercontent.irccloud-cdn.com/file/SEazNmdK/image.png |
| 06:12 | <haxjs> | littledan: they may slightly related. i guess programmers see `const.suffix x = ...` and would not expect it could be in the same namespace of `const/let`. |
| 06:13 | <rbuckton> | Hmm: https://usercontent.irccloud-cdn.com/file/K9zrsL1i/image.png |
| 06:14 | <rbuckton> | It did a fairly good job understanding me, and it looks like it does now have attribution. I don't see a way to export it, however, but it could be useful for note-takers if something is missed. |
| 06:15 | <rbuckton> | rather, no way to export other than Copy/Paste, since you *can* select the text of the transcription |
| 06:16 | <haxjs> | great! where can i download preview version of team so i can try it tommorow? |
| 06:17 | <rbuckton> | IIRC, you can opt into preview features from the settings of the desktop app: https://usercontent.irccloud-cdn.com/file/7X4DmJN4/image.png |
| 06:19 | <haxjs> | Get it! Thank u! |
| 17:06 | <gibson042> | I just ran across another spatial chat system: https://gather.town/ . It's two-dimensional, which I like, and has a convenient full-space map |
| 17:14 | <shu> | gibson042: how's the cpu/gpu consumption on it? |
| 17:15 | <ljharb> | my company uses that. i vastly prefer hubs. |
| 17:15 | <devsnek> | we used theonline.town once |
| 17:16 | <ljharb> | gather.town is basically the same as theonline.town |
| 17:16 | <shu> | are there domains on .town that are these spatial chat apps? |
| 17:16 | <shu> | that aren't* |
| 17:16 | <devsnek> | looks like gather took online and commercialized it |
| 18:00 | <gibson042> | cpu/gpu seem to not be excessive, but I'm not sure how they compare to other options |
