00:47 | <ryzokuken> | does the meeting start dot at time? |
00:47 | <ryzokuken> | if one of the chairs could let me in, I'd ensure that my tech setup works one final time π |
01:01 | <devsnek> | hello everyone! |
01:03 | <Bakkot> | morning all |
01:06 | <ljharb> | rkirsling: you can't change your name unless you're a guest |
01:07 | <rkirsling> | π |
01:08 | <ljharb> | are there slides being shown? |
01:08 | <devsnek> | yes |
01:08 | <ljharb> | damnit teams |
01:09 | <ljharb> | aha, switching out of the app and back fixed it for some reason |
01:10 | <ljharb> | fun hackmd thing, apparently making the days collapsible prevents clicking on links contained in the day heading |
01:14 | <jorendorff> | All the features are implemented in SM, actually, the slides are out of date |
01:14 | <jorendorff> | but, they're not shipping yet |
01:14 | <jorendorff> | to be fair, private methods are inefficient as implemented, we have to fix them before shipping |
01:14 | <ljharb> | jorendorff: yay, put that on the queue :-p |
01:17 | <littledan> | yay! |
01:19 | <shu> | who is speaking? |
01:19 | <ljharb> | "wenbo z" |
01:20 | <ljharb> | would it be useful for the chairs to clarify how our process works prior to a future advancement request? |
01:21 | <haxjs> | Wenbo Zhao is the GA rep of 360. |
01:24 | <akirose> | fyi devsnek i rearranged you and Frank so both of you have your own topics back to back instead of across two days |
01:24 | <devsnek> | ok |
01:24 | <devsnek> | if it makes the schedule better feel free to split mine up |
01:25 | <akirose> | Frank wanted his to be back to back and it worked really nicely with yours |
01:25 | <akirose> | but thank you β₯οΈ |
01:32 | <Bakkot> | re: mark's point: that shorthand syntax was indeed in an earlier version of this proposal; strong agree |
01:32 | <shu> | i see a lot of queue items reacting to the WeakMap-like reification: IIUC that's an explicit non-goal of this proposal and not included in this proposal |
01:32 | <littledan> | I deleted my queue item since I agree with Mark's various points; I don't have more to add |
01:32 | <devsnek> | i explicitly want us to reify private fields :( |
01:33 | <shu> | sure, that's not this proposal |
01:33 | <jorendorff> | Is it really true no language binds the name of a field to some reification of that field, rather than the value of the field? |
01:34 | <jorendorff> | statements of the form "no programming language has ever done X" have a low prior probability for me |
01:34 | <Bakkot> | jorendorff among languages which use `.` for field access? none that I'm aware of, though I don't know every language |
01:34 | <ljharb> | does any other language actually avoid breaking instance privacy with a reflection mechanism? |
01:34 | <rickbutton> | yep |
01:34 | <rickbutton> | no |
01:35 | <rickbutton> | i read that backwards |
01:37 | <littledan> | I'm really having trouble making sense of haxjs 's arguments here |
01:38 | <shu> | ^ i am having trouble as well |
01:38 | <littledan> | Mark has explained how reification would be different from the syntax here (and has done so several times previously), both in terms of syntax and capabilities |
01:39 | <jorendorff> | ok so ... Alloy isn't an OO language, it's a relational language, but it uses `.` and fields are reified |
01:39 | <shu> | jorendorff: fascinating, link? |
01:39 | <jorendorff> | Alloy also isn't ... a programming language |
01:39 | <jorendorff> | but it IS fascinating |
01:39 | <devsnek> | the specification language? |
01:39 | <jorendorff> | yeah |
01:40 | <devsnek> | that thing is weird lol |
01:40 | <jorendorff> | shu: the best thing to read AFAIK is the language reference http://alloytools.org/download/alloy-language-reference.pdf |
01:40 | <rkirsling> | is it like, prolog but less expressive? |
01:42 | <rkirsling> | er like at a glance it's reminding me of something like LEAN or Coq but again...smaller? |
01:43 | <jorendorff> | huh. i think it must be weaker than Lean and Coq. feels more along the lines of prolog/datalog, but i don't know enough about that space to say more :-\ |
01:43 | <ljharb> | jridgewell: you're a bit quiet btw |
01:44 | <rkirsling> | Yeah. I've used each of Coq and Lean a bit but never Prolog (though I know it's Yulia's favorite) |
01:44 | <jorendorff> | i like Lean |
01:53 | <jorendorff> | yes, good point. i would definitely assume that `#x` is an expression I can use anywhere, and then i would see the syntax error once, and then I'd be like "well this is stupid" (unjustly) and probably go look it up to make sure i understood |
01:54 | <rkirsling> | I mean I *definitely* don't think that anything in JavaScript should lead one to believe that `this.` would ever be droppable |
01:55 | <jorendorff> | yyyes, but mark's objection comes as a surprise to me, as worded |
01:55 | <rkirsling> | yeah sorry that was in reaction to his statement, not yours π |
01:56 | <jorendorff> | we're on the same page (you and I, not mark and I) |
01:56 | <rkirsling> | yeah |
01:57 | <devsnek> | what if we just make `#x` a thing you can use anywhere |
01:57 | <ljharb> | that would be the "private symbol" reification, which mark specifically has said wouldn't work |
01:58 | <jridgewell> | I think Waldemar actually made Mark's point stronger |
01:58 | <littledan> | I agree with Jordan here on this subset/syntax error point; this has been what the design of private fields and methods was based around |
01:58 | <jridgewell> | Having `#x.get` be something different than `this.#x.get` would be very surprising |
01:59 | <jridgewell> | (That' doesn't mean Mark is arging that `#x` should be shorthand for `this.#x`) |
01:59 | <jorendorff> | currently, if you go to type `this.toString()` and accidentally type `toString()` instead, it's weird |
01:59 | <jridgewell> | `#x` in Mark's comment would be a WeakMap |
02:00 | <devsnek> | who needs `#x.get(v)` when you have `v[#x]` |
02:00 | <jridgewell> | So `#x.get` would take an object to get from, where `this.#x.get` would be the value at `this.#x`, which apparently has a map API |
02:00 | <jorendorff> | but that doesn't seem to be a big problem? |
02:00 | <jridgewell> | devsnek: You can't pass around syntax lik e`v[#x]` |
02:00 | <jridgewell> | You could pass around `#x` if it reified to a map |
02:01 | <jorendorff> | jridgewell: I think devsnek means `#x` should be more symbol-like |
02:01 | <devsnek> | yeah like we should just make it a value |
02:01 | <jorendorff> | in that view, it is a value and you can pass it around |
02:01 | <devsnek> | every possible suggestion is causing confusion with expressions in some way |
02:01 | <jridgewell> | If it becomes a Private Symbol, then that would work |
02:01 | <jridgewell> | But I don't think we're going to get them |
02:01 | <devsnek> | confusion with them cuz lhs of `in`, confusion cuz `#x.y`, confusion cuz `x[#y]` |
02:01 | <devsnek> | there's no winning |
02:02 | <jorendorff> | hear me out, let's start over with R4RS scheme... |
02:02 | <jorendorff> | </joke> |
02:03 | <shu> | R*4*RS |
02:04 | <jorendorff> | shu: i think tradition has it that the first one you personally implemented is the last good one |
02:04 | <devsnek> | crazy to me that private symbols is outside the realm of people's mental models but adding a new kind of object is a-ok |
02:04 | <shu> | ah, very well |
02:06 | <devsnek> | new decorators look reasonable iirc |
02:06 | <ryzokuken> | super excited about it! |
02:10 | <michaelficarra> | I think this is supposed to say "bar"? |
02:10 | <michaelficarra> | Also foo/bar are terrible names, please don't use them in examples |
02:10 | <michaelficarra> | use Pokemon |
02:11 | <devsnek> | use js ui libraries |
02:11 | <devsnek> | there are thousands to choose from |
02:12 | <ryzokuken> | pokemon are fun tho |
02:14 | <jorendorff> | dynamic language features are also fun |
02:14 | <jorendorff> | I think we're meant to be learning that fun is bad |
02:14 | <devsnek> | dynamic scoping! |
02:15 | <rkirsling> | yeah that extended pokemon example was inspiring |
02:16 | <rkirsling> | definitely will use game references in future presentations |
02:17 | <ljharb> | might be a fun game, without googling, figure out which obscure universe is being referenced by names of things |
02:17 | <devsnek> | slide show but everything is don't hug me i'm scared references |
02:17 | <rkirsling> | devsnek: approve |
02:18 | <rkirsling> | throw error upon setting color to green |
02:18 | <Bakkot> | should start using the names of mathematical objects |
02:18 | <devsnek> | `let lattice = 4` |
02:18 | <ljharb> | for example, zummi/gruffi/grammi/tummi/sunni/cubbi/gusto/chummi |
02:18 | <ryzokuken> | I thought it would be more fun if people actually got the reference lol |
02:19 | <akirose> | ljharb: too easy |
02:20 | <akirose> | also just reading that makes my teeth hurt |
02:20 | <shu> | Bakkot: you mean like x, x', x'', x''', x'''' |
02:20 | <ljharb> | akirose: only too easy for the cool kids |
02:20 | <leobalter> | did we all lost Chris' audio for a few seconds? |
02:20 | <leobalter> | ok sounds like yes |
02:21 | <devsnek> | just teams things |
02:21 | <ryzokuken> | I had to perform 13 satanic rituals to make it work |
02:21 | <littledan> | whew, what a relief |
02:21 | <devsnek> | glad it wasn't 14 |
02:21 | <akirose> | ljharb: you mean people in their 30s |
02:21 | <ryzokuken> | (p.s. it still doesn't, I had to use chromium) |
02:21 | <gibson042> | ryzokuken: I too have used perl in anger |
02:22 | <leobalter> | my internet is also bouncy this week so it could be me as well |
02:22 | <ryzokuken> | lol |
02:22 | <devsnek> | wait when did this become not-tdz |
02:22 | <ljharb> | oops |
02:22 | <gibson042> | whoops |
02:22 | <akirose> | AHAHAHA |
02:22 | <mmarchini> | Teams is clearly trolling us |
02:22 | <shrutikapoor> | trololololol |
02:23 | <mmarchini> | Blocking proposal via technical issues |
02:23 | <ryzokuken> | petition to move to the most reliable mode of comms |
02:23 | <mmarchini> | π |
02:23 | <ryzokuken> | i.e. VNC for screenshare plus a SIP call |
02:23 | <leobalter> | is this the shareware version of Teams? |
02:23 | <devsnek> | lol |
02:23 | <leobalter> | pay for the full content |
02:24 | <ryzokuken> | "teams trial expired" |
02:24 | <leobalter> | This copy of Teams is not genuine |
02:29 | <rickbutton> | here just use this to activate: "FCKGW RHQQ2 YXRKT 8TG6W 2B7Q8" |
02:29 | <devsnek> | pf |
02:29 | <ryzokuken> | rickbutton: did you read the code from the CD? |
02:30 | <rickbutton> | from memory of course |
02:30 | <jridgewell> | Can else hear the WAREZ keygen music? |
02:30 | jridgewell | sees myself to TDZ |
02:31 | <michaelficarra> | how are people going to remember all these signatures for the different kinds of decorators and when they apply? |
02:32 | <devsnek> | aren't there just two |
02:32 | <devsnek> | (v, context) and ({ get, set }, context) |
02:32 | <michaelficarra> | I guess the same way people have to deal with options bags, look at the docs every time |
02:33 | <jridgewell> | I think this is actually the simplest decorators API yet. |
02:33 | <devsnek> | definitely the simplest one |
02:33 | <michaelficarra> | {method, initialiser} or something? |
02:33 | <akirose> | i can't imagine life without Alfred & Dash (& MDN) |
02:33 | <JemYoung> | I'm digging it so far |
02:33 | <akirose> | it's a lot to remember regardless |
02:33 | <akirose> | i'm not saying it's not a legitimate concernβit's a v real concern for me |
02:33 | <akirose> | but also, it's already a lot to remember |
02:33 | <jridgewell> | v2 API was overflowing with customization |
02:33 | <devsnek> | when someone recites the splice signature from memory |
02:33 | <michaelficarra> | yeah I either MDN or just go straight to the spec, depending if I know exactly where to look |
02:34 | <michaelficarra> | devsnek: offset, length, replacements array? is that right? |
02:34 | <rkirsling> | devsnek: I mean it's not `tar` flags at least |
02:34 | <devsnek> | idk i'd have to check |
02:34 | <devsnek> | for tar i just always pass `-xvf` |
02:34 | <devsnek> | idk what they do but it seems to work |
02:34 | <jridgewell> | variadic insertions, not an array |
02:35 | <rkirsling> | what about -c |
02:35 | <michaelficarra> | jridgewell: ah, so close |
02:35 | <devsnek> | idk what -c is so i can't comment |
02:35 | <rkirsling> | me neither |
02:35 | <jridgewell> | I use it as an interview question π |
02:35 | <devsnek> | oh yeah you like javascript? name every function |
02:35 | <michaelficarra> | jridgewell: please no! |
02:36 | <ljharb> | for tar i have to memorize eXtract Ze Files, Verbosely |
02:36 | <jridgewell> | Lol. My interview question uses it, but knowing the signature isn't required. |
02:36 | <rkirsling> | devsnek: name every function on the `Math` namespace would be hard enough |
02:36 | <rkirsling> | ljharb: ohh it was -z not -c |
02:37 | <rkirsling> | so close |
02:37 | <devsnek> | overall this proposal seems pretty good |
02:37 | <ljharb> | shu: which use cases do you find least compelling? |
02:38 | <shu> | ljharb: hm, the least? probably metadata personally |
02:38 | <ljharb> | gotcha |
02:38 | <devsnek> | metadata is take it or leave it |
02:38 | <shu> | i don't have a use case in mind that is much less compelling than the others as much as i have a use case that is much more compelling than the others: fields |
02:38 | <rkirsling> | I've always felt terrified about the decorators proposal so this definitely seems like the least terrifying iteration |
02:38 | <shu> | class decorators as well, i don't find super compelling |
02:38 | <rkirsling> | oops I meant to say that in tdz |
02:38 | <devsnek> | shu: enough that you don't want them to be part of the proposal? |
02:39 | <shu> | devsnek: hard to say right now |
02:39 | <shu> | devsnek: i think the class decorator use case is probably fine with existing function call syntax, unless i'm missing something |
02:40 | <devsnek> | wdym "fine with existing function call syntax" |
02:40 | <shu> | devsnek: class C {} \n decorate(C) ? |
02:40 | <jridgewell> | `let Decorated = decorate(class Inner {})` |
02:41 | <devsnek> | isn't that true of everything |
02:41 | <shu> | not of fields, no |
02:41 | <devsnek> | decorate(C) where C has fields |
02:41 | <michaelficarra> | so decorated methods can be new'd? |
02:41 | <jridgewell> | That wouldn't give access to private fields |
02:41 | <devsnek> | is there some bad thing about class decorators i'm not aware of |
02:41 | <shu> | devsnek: there's no way to do the transform of data property -> getter/setter pair with function calls |
02:42 | <ljharb> | michaelficarra: that seems like a good issue to file - ensuring that decorated methods can't be newed |
02:42 | <michaelficarra> | ljharb: it doesn't sound like an issue, it sounds inevitable with this design |
02:43 | <ljharb> | ah right, it'd be weird if the decorator return got its [[Construct]] changed, so the only alternative is forcing them to `return { foo() {} }.foo` or something :-. |
02:44 | <michaelficarra> | yep |
02:44 | <Bakkot> | alternatively, we should make methods newable |
02:44 | <Bakkot> | they should always have been |
02:44 | <Bakkot> | static methods at the very least |
02:44 | <devsnek> | very important use case |
02:44 | <ljharb> | static methods, fair. |
02:45 | <devsnek> | at that point all methods |
02:45 | <michaelficarra> | Bakkot making things difficult |
02:46 | <jorendorff> | This really seems like it will pare down to a very, very nice MVP |
02:47 | <jridgewell> | keith_miller: What are the "local variable semantics" |
02:47 | <devsnek> | aside from metadata everything proposed seems reasonable |
02:47 | <keith_miller> | jridgewell: var @myDecorator foo = x; |
02:47 | <jridgewell> | Ahh |
02:48 | <keith_miller> | I assume that's like a getter on the scope variable |
02:48 | <leobalter> | I can confirm what Yehuda has said from our code base. |
02:48 | <keith_miller> | but still it's a bit wierd |
02:48 | <keith_miller> | I hadn't considered that before this meeting so maybe that's my b |
02:48 | <leobalter> | it's pretty convenient to add common accessors |
02:51 | <Bakkot> | re: littledan's point right now: how is a class decorator a position where there is no function call possible right now? |
02:51 | <Bakkot> | I am confused |
02:51 | <ljharb> | `export class C { }`? |
02:51 | <devsnek> | ^ |
02:52 | <ljharb> | also name inference with `const C = decorate(class { })` |
02:52 | <Bakkot> | `export let C = foo(class C{})` is equivalent |
02:52 | <ljharb> | sure, but then you have to repeat the name |
02:52 | <Bakkot> | that does not come _close_ to justifying new syntax |
02:52 | <akirose> | sorry about the english idiom, non-native english speakers |
02:52 | <devsnek> | Bakkot: you can also manually rewrite your fields to be getter/setters |
02:53 | <Bakkot> | devsnek right, but you have to do it manually, rather than ecapsulating it with a function call |
02:53 | <Bakkot> | but here you can do the encapsulation with the function |
02:53 | <Bakkot> | so I don't know what littledan means |
02:53 | <jridgewell> | I agree with Bakkot here |
02:54 | <akirose> | 10 minutes |
02:54 | <jridgewell> | Burden of writing a `decorate(class {})` seems minimal compare to decorating a field |
02:56 | <jorendorff> | +2 to shu's last sentiment |
02:57 | <rbuckton> | hmm. I can't get to Reflector to get the link to TCQ ... |
02:57 | <devsnek> | looking forward to class {} |> decorate1 |> decorate2 |
02:57 | <rbuckton> | nm, working now. |
02:59 | <gibson042> | β€οΈ |
02:59 | <akirose> | wsdferdksl: should that be a new topic isntead of a reply? |
03:00 | <leobalter> | akirose: I believe it's a feedback on the current topic |
03:00 | <akirose> | i read it as parallel |
03:00 | <leobalter> | understanding the entire design as in a single proposal |
03:01 | <shu> | rbuckton: i'll delete my queue item if you've read it? |
03:02 | <rbuckton> | I've read it |
03:03 | <leobalter> | shu: would it be helpful for a better overview if I prepare a full set of Test262 tests for this proposal? I'd do my best to separate each part. |
03:03 | <leobalter> | like, I'm trying to improve the trade off |
03:04 | <shu> | leobalter: sorry i don't understand the question |
03:04 | <shu> | a better overview of what? |
03:05 | <rbuckton> | There are caveats to consider with class decorators, such as this case: |
03:05 | <rbuckton> | ``` |
03:05 | <rbuckton> | @decorator |
03:05 | <rbuckton> | class C { |
03:05 | <rbuckton> | static #x = 1; |
03:05 | <rbuckton> | static method() { |
03:05 | <rbuckton> | this.#x // could throw if `decorator` replaces class with subclass |
03:05 | <rbuckton> | C.#x // ok, accessing inner `C` |
03:05 | <rbuckton> | new C() // but this produces an inner `C`, not an outer `C`. Fixing this breaks the line above |
03:05 | <rbuckton> | } |
03:05 | <rbuckton> | } |
03:05 | <rbuckton> | ``` |
03:05 | <ljharb> | rbuckton: why would it throw if it's a subclass of C? |
03:05 | <Bakkot> | it sounded like class decorators were intended to replace the inner binding |
03:05 | <rbuckton> | Its a private static field. |
03:06 | <Bakkot> | ljharb static private has this problem |
03:06 | <rbuckton> | They throw for subclasses of `C`. |
03:06 | <haxjs> | another footgun |
03:06 | <ljharb> | oh right |
03:06 | <leobalter> | I was hoping I could provide some form to check each part of this proposal. I'm offering what I know how to do. It doesn't look like much valuable to do it before Stage 3 anyway |
03:06 | <ljharb> | i forgot because i have no use cases for private static |
03:06 | <leobalter> | I'm too tired, I'm sorry my ideas are too raw |
03:07 | <jorendorff> | littledan: nice work |
03:07 | <littledan> | jorendorff: Thank you |
03:15 | <rbuckton> | TypeScript's decorators rewrite the inner bindings of `C` to point to the class result of the decorator: |
03:15 | <rbuckton> | ``` |
03:15 | <rbuckton> | var _x; |
03:15 | <rbuckton> | var C_1; |
03:15 | <rbuckton> | let C = C_1 = class C { |
03:15 | <rbuckton> | static method() { |
03:15 | <rbuckton> | __classPrivateFieldGet(this, _x); // throws for subclass |
03:15 | <rbuckton> | __classPrivateFieldGet(C_1, _x); // throws for subclass |
03:15 | <rbuckton> | return new C_1(); // creates "decorated" C |
03:15 | <rbuckton> | } |
03:15 | <rbuckton> | }; |
03:15 | <rbuckton> | _x = new WeakMap(); |
03:15 | <rbuckton> | _x.set(C, 1); |
03:15 | <rbuckton> | C = C_1 = __decorate([ |
03:15 | <rbuckton> | decorate |
03:15 | <rbuckton> | ], C); |
03:15 | <rbuckton> | ``` |
03:15 | <rbuckton> | Except that TypeScript errors on `static #x` currently. There's no easy way *inside* the class to reference the binding *outside* of the class, currently [1]. This might be way haxjs was suggesting class meta properties yesterday (i.e., `class.current`, `class.decorated`) as a way to distinguish between the two. |
03:15 | <rbuckton> | [1] Other than `let C = @decorator class { ... }` maybe? |
03:16 | <rbuckton> | s/be way/be why |
04:02 | <ljharb> | akirose: robpalme update queue? |
04:02 | <devsnek> | i like this proposal |
04:03 | <akirose> | got u |
04:03 | <ljharb> | ty |
04:03 | <akirose> | holy shit i love this already |
04:05 | <michaelficarra> | please no more string literals |
04:05 | <michaelficarra> | also this is already valid syntax |
04:06 | <devsnek> | yeah but who is doing `````` |
04:06 | <devsnek> | that will just throw |
04:06 | <michaelficarra> | devsnek: me, and no it won't |
04:06 | <devsnek> | ? |
04:06 | <Bakkot> | where's that gist |
04:06 | <devsnek> | strings are not functions |
04:06 | <michaelficarra> | tags can return tags |
04:06 | <jridgewell> | Yah, michaelficarra provided an `append` tagged template literal which continues to return a function after every tag invocation |
04:07 | <jridgewell> | But untagged is good to go. π |
04:07 | <Bakkot> | he provided it four years ago, even |
04:07 | <Bakkot> | https://gist.github.com/michaelficarra/70ce798feb25fdc91508f387190053a1 |
04:07 | <devsnek> | so if you use append with empty strings on both sides |
04:07 | <devsnek> | as is very common |
04:07 | <devsnek> | :unconvinced: |
04:08 | <shu> | i am really confused by the previous slide |
04:08 | <shu> | the problem is that... you didn't dedent the string, therefore it's not === to an un-dedented string? |
04:08 | <shu> | why is that a problem? |
04:08 | <Bakkot> | yeah I am also confused |
04:08 | <jridgewell> | The syntax never exposes an un-dedented strings |
04:08 | <jridgewell> | Where the API can expose both |
04:08 | <jridgewell> | Whether that's really a problem is up to the dev |
04:09 | <drousso> | wouldn't this not work if the first line is not a newline? |
04:10 | <devsnek> | String.dedent is great except composing with other tag functions |
04:10 | <jridgewell> | Correct, unless that first line had the same common indentation. |
04:10 | <rbuckton> | https://usercontent.irccloud-cdn.com/file/0A5rHMJe/image.png |
04:11 | <michaelficarra> | Bakkot: scared me for a second there |
04:11 | <michaelficarra> | thought we were gonna have to fight |
04:12 | <littledan> | the syntax seems nice so that it can be based on the indentation where the opening quote is |
04:12 | <devsnek> | is there a widely understood way to compose template tag functions? |
04:12 | <rbuckton> | Also, this is valid code that executes and can be well behaved: https://usercontent.irccloud-cdn.com/file/KvA4SWj3/image.png |
04:12 | <rkirsling> | nice |
04:12 | <devsnek> | rbuckton: look up :P |
04:13 | <littledan> | let's use #` `# |
04:13 | <littledan> | html#`<div/>`# |
04:13 | <littledan> | everything with #! |
04:13 | <littledan> | tbh @ would work here as well |
04:13 | <rbuckton> | Scheme, but with ## instead of () |
04:14 | <michaelficarra> | devsnek: I'd love to know if you fin an answer to that question |
04:14 | <devsnek> | what |
04:14 | <littledan> | #${ }# replaces ( ) |
04:14 | <michaelficarra> | *find |
04:14 | <michaelficarra> | > is there a widely understood way to compose template tag functions? |
04:14 | <devsnek> | michaelficarra: i put it on the queue |
04:14 | <devsnek> | that's my primary reason for preferring the syntax |
04:15 | <devsnek> | if there's some easy way to compose String.dedent with other tags then i'm good with it |
04:15 | <michaelficarra> | uuhhhh that doesn't solve the problem still |
04:15 | <rkirsling> | oh damn we got elang on the queue |
04:15 | <devsnek> | E also had promises, now look where we are |
04:16 | <devsnek> | michaelficarra: my problem is not for N template it is for 1 template so it solves it for me :P |
04:16 | <devsnek> | s/template/tag/g |
04:16 | <michaelficarra> | devsnek:boring |
04:16 | <devsnek> | lol |
04:17 | <devsnek> | i just realized everything we're discussing is not stage 1 relevant |
04:18 | <michaelficarra> | true, I don't see this failing to reach stage 1 |
04:19 | <Bakkot> | littledan "it can be based on the indentation where the opening quote is" would be bad, it makes the whitespace outside of the ``` significant |
04:19 | <shu> | i am now super confused |
04:20 | <rkirsling> | yeah none of this blocks stage 1 lol |
04:20 | <devsnek> | wont' stop us from discussing it |
04:20 | <littledan> | Bakkot: OK, if this is taken to be bad, I prefer a stdlib tag as well |
04:20 | <rkirsling> | if we can convince the champions to focus on the non-syntactic approach at this point, that'd be great, but not required |
04:24 | <haxjs> | does ``` conflict with markdown syntax?? |
04:24 | <Bakkot> | ? |
04:24 | <ljharb> | not in the sense that markdown syntax doesn't work in a js context |
04:24 | <ljharb> | conceptually, sure, it's also the same as "preformatted text" in slack or a bunch of other markdownish contexts |
04:24 | <haxjs> | i mean if u want to embed js code in markdown or verse vice |
04:25 | <ljharb> | markdown syntax also has single backticks |
04:25 | <ljharb> | so template literal syntax already conflicts. |
04:25 | <haxjs> | markdown could use `` double backtick |
04:25 | <jridgewell> | There was an option to allow 5 ticks in a row for markdown |
04:25 | <haxjs> | at least standard markdown |
04:25 | <jridgewell> | Or 7 |
04:25 | <jridgewell> | etc |
04:25 | <haxjs> | oh ! |
04:25 | <haxjs> | let's use 7 ``````` |
04:26 | <haxjs> | not sure i enter the right count :) |
04:26 | <jridgewell> | Any number of ticks would continue until we encounter the same number of ticks |
04:26 | <rbuckton> | Markdown doesn't conflict with JavaScript. Also, markdown supports _n_-backticks for nesting: |
04:26 | <rbuckton> | ``` |
04:26 | <rbuckton> | `` allows ` in md `` |
04:26 | <rbuckton> | ``` |
04:28 | <haxjs> | but too many backticks just harm my eyes... :) really hope we can have some easy syntax :) |
04:28 | <rbuckton> | Somewhat amusing, I do have code that does something like this: |
04:28 | <rbuckton> | ``` |
04:28 | <rbuckton> | const fence = "```"; |
04:28 | <rbuckton> | markdown` |
04:28 | <rbuckton> | ${fence}typescript |
04:28 | <rbuckton> | ... |
04:28 | <rbuckton> | ${fence} |
04:28 | <rbuckton> | `; |
04:28 | <rbuckton> | ``` |
04:28 | <rbuckton> | (for mixing trusted and untrusted content when generating documentation for VS Code) |
04:28 | <rbuckton> | That didn't work well, heh. |
04:28 | <gibson042> | inline code spans can be wrapped in backtick strings of any length, e.g. ```code```: https://spec.commonmark.org/0.29/#code-spans |
04:29 | <rbuckton> | ``` |
04:29 | <rbuckton> | const fence = "`".repeat(3); |
04:29 | <rbuckton> | markdown` |
04:29 | <rbuckton> | ${fence}typescript |
04:29 | <rbuckton> | ... |
04:29 | <rbuckton> | ${fence} |
04:29 | <rbuckton> | `; |
04:29 | <rbuckton> | ``` |
04:29 | <rbuckton> | That worked better... |
04:31 | <gibson042> | and code fences use 3 or more consecutive backticks |
04:35 | <rkirsling> | ooh π indeed |
04:37 | <michaelficarra> | yay, I much prefer Instant |
04:37 | <michaelficarra> | though I am bummed about negative durations |
04:37 | <Bakkot> | still don't understand your concern there |
04:37 | <Bakkot> | time has direction |
04:38 | <michaelficarra> | it's conflating the magnitude and the direction |
04:38 | <Bakkot> | it isn't conflating |
04:38 | <Bakkot> | it's representing both |
04:38 | <michaelficarra> | a duration is just a magnitude |
04:38 | <ljharb> | it's combining, surely |
04:38 | <haxjs> | if every other lib/lang have negative duration, we should have it :) |
04:38 | <michaelficarra> | sure, combining |
04:38 | <ljharb> | haxjs: in general i don't agree with that logic, but here i do :-) |
04:39 | <Bakkot> | whoosh, this is a _giant_ API |
04:39 | <Bakkot> | not necessarily bad but it is going to take forever to review it |
04:39 | <haxjs> | ljharb: I mean we need a strong reason to be difference. :) |
04:39 | <ljharb> | Bakkot: they're hoping we can all review it in 2 months |
04:40 | <michaelficarra> | they best be ready to rebase on top of 2007 because I'm not doing it for them |
04:40 | <rkirsling> | Bakkot: yeah it's basically the size of 402 |
04:40 | <michaelficarra> | (quick, someone merge 2007) |
04:40 | <haxjs> | yeah it's a giant api and changing ... |
04:40 | <rkirsling> | so we need to consider it as if reviewing an entirely new spec |
04:40 | <Bakkot> | haxjs the idea is that they'll stop changing it and tell us and then we can review |
04:40 | <Bakkot> | which I think is what is currently happening |
04:41 | <Bakkot> | michaelficarra not sure they have a spec at all; I think the work was mostly in the polyfill |
04:41 | <haxjs> | bakkot: glad to hear that! but it seems there are still some new draft for new additions in the repo |
04:41 | <ystartsev> | Bakkot: hm, the spec isn't up to date? |
04:42 | <Bakkot> | ystartsev not sure, to be clear, I haven't been following closely |
04:42 | <Bakkot> | that was true at some point in the past |
04:42 | <haxjs> | like LocalDateTime (i am not sure ,this is what i saw last week) |
04:42 | <gibson042> | there's pending work in both the spec and the polyfill, but I think the polyfill is ahead |
04:43 | <michaelficarra> | someone post the Twitter vote link from the slides, I am too lazy |
04:43 | <ystartsev> | gibson042: we have done a review of the spec text in preparation for november, is that far behind? |
04:43 | <littledan> | btw the original Temporal API had something representing LocalDateTime, and it was a change from a couple years ago to try to remove it, for minimalism. The ensuing investigation taught us, Maggie Pint was right about ensuring it was present |
04:44 | <ljharb> | ystartsev: my sense from watching the repo is that it seems like it's changing in significant ways every day or three |
04:44 | <ystartsev> | hm... ok. is the plan still to advance this in november? |
04:45 | <gibson042> | ystartsev: I think so, many things will likely not change but you'll definitely need to re-review and it will probably feel more comprehensive than you'd like |
04:45 | <shu> | oh, we need to review Temporal for advancement by november? |
04:45 | <gibson042> | https://twitter.com/justingrantjg/status/1308619968632688640 |
04:45 | <ljharb> | ystartsev: i assume that's still the hope, i'll be asking about review |
04:45 | <ljharb> | shu: yes, that's what they said in july |
04:45 | <michaelficarra> | wait, different calendars still use ISO 8601 instant formatting? |
04:45 | <shu> | okay, thanks |
04:45 | <Bakkot> | I am not confident we will all be able to review and address comments by november |
04:45 | <ystartsev> | gibson042: getting our domain experts to review it is quite a bit of work. i want to make sure that i don't ask them unnecessarily |
04:45 | <rkirsling> | hoo wow `DateAndTime` would be real bad |
04:45 | <ljharb> | Bakkot: me neither, which is what i said in july |
04:45 | <gibson042> | then I would hold off |
04:46 | <shu> | i would request the champion group to hold tutorial VCs for the reviewers + editors, if possible |
04:46 | <gibson042> | the current plan/hope is to have the spec ready sometime next month; there should be a slide on that coming up |
04:46 | <haxjs> | I hope we can have some time to introducing it to users and collect feedback before stage 3. |
04:46 | <gibson042> | with hope for advancement in January IIRC |
04:47 | <ystartsev> | gibson042: I've already requested a review and had it done prior to this meeting. It would be really good to only do that when the spec is ready. But outside of that there were no concerns |
04:47 | <michaelficarra> | shu: I think that's a good idea |
04:47 | <ystartsev> | ditto, i like shu's idea |
04:47 | <ljharb> | gibson042: ah ok, that's newly extended |
04:48 | <rkirsling> | I'm not a reviewer but I would like to attend such a meeting too |
04:48 | <jridgewell> | shu: Are we chartering a incubator again? |
04:48 | <jridgewell> | If so, can we sign up String.dedent? |
04:49 | <shu> | jridgewell: most definitely |
04:49 | <shu> | jridgewell: until further notice, there will be a 15-min chartering on the last day every meeting |
04:49 | <jridgewell> | π |
04:50 | <littledan> | ystartsev: Yeah, sorry about the confusion about stability; I thought the expectation was that reviews would be requested before the next meeting, so I guess there wasn't a particular effort to telegraph the continued development |
04:50 | <michaelficarra> | jridgewell: you don't think you got enough feedback during plenary? |
04:51 | <ystartsev> | littledan: no problem, its not too much of an issue and we already have a good idea going into the next review |
04:52 | <littledan> | note that the champion group has done a lot of work to document rationale, but it's definitely a good idea to group it in one place |
04:52 | <jridgewell> | Yes, there's feedback, but I think we can solve some of the open questions during an incubator |
04:53 | <jridgewell> | Eg, whitespace-only lines affect "common whitespace", or whether to allow mixing whitespace. |
04:53 | <jridgewell> | These don't need full committee involvement to decide. |
04:53 | <michaelficarra> | jridgewell: are there open issues for these things? I'd prefer to weigh in on the issue tracker |
04:54 | <jridgewell> | Whitespace-only lines: https://github.com/mmkal/proposal-multi-backtick-templates/issues/13 |
04:54 | <jridgewell> | I'll make one for mixing whitespace. |
04:55 | <Bakkot> | should look at what other languages do, too |
04:55 | <Bakkot> | often there is a common thing all languages do and we can just go with that |
04:55 | <jridgewell> | Each one seems to do something different. π¬ |
04:56 | <jridgewell> | I personally like Python's impl, but there's enough competing prior art to choose anything. |
04:56 | <akirose> | my least favorite game: "this meeting has more [pick a dude's name] than women" π |
04:57 | <Bakkot> | a depressing game |
04:57 | <rkirsling> | yeah this is a bad one |
04:57 | <rkirsling> | you know it's bad when "Ross" is a name in the running |
04:57 | <ystartsev> | is it just me and aki this time around? |
04:58 | <ljharb> | ystartsev: shrutikapoor |
04:58 | <ystartsev> | ah good |
04:58 | <akirose> | No! shrutikapoor ! |
04:58 | <akirose> | shrutikapoor: you're paypal, right? |
04:58 | <ystartsev> | i didn't see the name in the call but maybe she was on an earlier session |
04:59 | <ljharb> | wsdferdksl: your audio's getting a bit hard to hear |
05:01 | <Bakkot> | fun fact: you can spread own accessors if they're enumerable |
05:02 | <michaelficarra> | wow I did not know that |
05:03 | <ljharb> | that is true |
05:04 | <Bakkot> | (no reason to prefer that over frozen own data properties, though) |
05:04 | <Bakkot> | well, actually, I guess maybe laziness? |
05:04 | <haxjs> | record/tuple already have immutable own property? (or at least it behave like that?) |
05:04 | <keith_miller> | littledan: +1 on tutorial |
05:05 | <ljharb> | Bakkot: laziness but also, those own accessors would have to be nonconfigurable anyways to ensure immutability |
05:05 | <Bakkot> | yup |
05:05 | <jridgewell> | michaelficarra: mixing whitespace https://github.com/mmkal/proposal-multi-backtick-templates/issues/16 |
05:13 | <michaelficarra> | whose phone keeps beeping? akirose? |
05:14 | <akirose> | nope i'm HW muted |
05:21 | <akirose> | i know i can be a little polyanna about things |
05:21 | <akirose> | but |
05:21 | <akirose> | i love this |
05:22 | <rkirsling> | no need to hesitate; language-level i18n is great |
05:26 | <ryzokuken> | i18n is amazing in general |
05:27 | <akirose> | YOOOOOOOO |
05:27 | <akirose> | BUDS |
05:27 | <haxjs> | i18n is hard! really like we improve the api ability to solve the problems :) |
05:27 | <akirose> | we need note-takers |
05:27 | <akirose> | can someone hop on |
05:27 | <ryzokuken> | akirose: let me try |
05:27 | <akirose> | so i don't have to interrupt |
05:27 | <akirose> | ty |
05:27 | <akirose> | (you don't have to take notes of the presentation of slides) |
05:28 | <ryzokuken> | okay, thanks! |
05:28 | <akirose> | having three cursors ready to go would be dope |
05:31 | <ljharb> | ystartsev: sorry, fixed the slides perms |
05:31 | <ystartsev> | The library exists but i don't know much about it ... that would be zibi or waldo |
05:31 | <ystartsev> | so, i have no idea in case anyone is wondering |
05:31 | <ystartsev> | ljharb: thanks! |
05:45 | <Bakkot> | I have no opinions on this issue |
05:45 | <Bakkot> | all options kinda suck |
05:46 | <devsnek> | lol |
05:46 | <michaelficarra> | oh good point from Mark |
05:46 | <devsnek> | we had this problem in node |
05:46 | <devsnek> | i don't remember how we solved it because its 1am |
05:47 | <devsnek> | aha we strictly control the type of the option so you can check `option: invalid type` throwing for it to be there |
05:48 | <Bakkot> | ljharb are you concerned that making an error into a non-error is breaking? |
05:49 | <devsnek> | Bakkot: new code can't be used on old runtimes |
05:49 | <ljharb> | in options bags only, yes |
05:49 | <Bakkot> | what's special about options bags? |
05:50 | <ljharb> | throwing on an extra property is the same as throwing on an extra argument |
05:50 | <ljharb> | we don't make apis that do the latter |
05:50 | <devsnek> | throwing on extra properties is weird to me |
05:51 | <Bakkot> | this isn't "extra property", it's "an unexpected value", as I understood it |
05:51 | <Bakkot> | "an unexpected value of an expected property" |
05:51 | <shu> | yes, that was the clarification just now |
05:51 | <devsnek> | yeah that should throw |
05:52 | <shu> | ljharb: i think you're misunderstanding |
05:52 | <shu> | shane is not proposing anything about unknown properties afaict? |
05:53 | <jridgewell> | Add a "clarifying statement" on TCQ? |
05:53 | <ljharb> | thanks |
05:55 | <ljharb> | my bad on misunderstanding the question i guess |
05:56 | <devsnek> | seems philipp misunderstood as well? |
06:04 | <ljharb> | many helpful anonymous animals |
06:04 | <ljharb> | (do that few people have a google account?) |
06:05 | <rkirsling> | anonymous-ness is document-specific |
06:05 | <rkirsling> | presumably everyone has a google acct |
06:05 | <devsnek> | anonymous is due to it being public |
06:05 | <jridgewell> | You have to click a button for you to expose your Google account |
06:05 | <ljharb> | oh, which button |
06:05 | <devsnek> | that one |
06:05 | <jridgewell> | By default on pub docs, everyone is anonymous |
06:05 | <ljharb> | i wanna click it, which one |
06:05 | <jridgewell> | It's at the top right... |
06:06 | <jridgewell> | It has a little pop up when you first open Docs |
06:06 | <ljharb> | ok but i've opened docs like a thousand times and i see no popup |
06:06 | <ljharb> | i'm logged into my gmail |
06:06 | <ljharb> | and the only name i see in the list is rob's |
06:07 | <jridgewell> | π€·ββοΈ |
06:07 | <jridgewell> | There's always a pop-up fo rme |
06:08 | <ljharb> | i wonder if it has to be explicitly shared with someone for their name to show up |
06:08 | <michaelficarra> | I don't see this button either |