18:15 | <nicolo-ribaudo> | jschoi: I'm reading your slides, and at slide 6 there is a # that probably should be a @ |
18:54 | <ljharb> | the auto-cooldown bot worked well |
19:25 | <TabAtkins> | did the bot trigger recently? or is this just a historic observation? |
20:17 | <James DiGioia (mAAdhaTTah on GH)> | It triggered on the topic bikeshed issue |
20:49 | <TabAtkins> | Ah, I'm not sure how I didn't see that, thanks |
20:56 | <TabAtkins> | And yup, that is precisely what that bot was installed for, hell yeah |
21:00 | <jschoi> | jschoi: I'm reading your slides, and at slide 6 there is a |
21:00 | <nicolo-ribaudo> | Yes |
21:00 | <nicolo-ribaudo> | Where you show ASI |
21:00 | <jschoi> | It triggered on the topic bikeshed issue |
21:01 | <James DiGioia (mAAdhaTTah on GH)> | People are mad Jordan is blocking valid identifiers |
21:02 | <jschoi> | Ah, I see. Well, I’m glad the bot worked, then…… |
21:03 | <jschoi> | …Maybe we should unlock it tomorrow or something. |
21:07 | <jschoi> | nicolo-ribaudo: I see it now; thank you; fixed! I think https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-1077038247 has a good point in that this is analogous to the ASI hazard with class fields without semicolons. We might want to make this case an early error to force developers to use parentheses if they don’t want to use semicolons. |
21:09 | <nicolo-ribaudo> | Or force them to use semicolons! (/s ?) |
21:53 | <TabAtkins> | While I'm generally quite strongly on the side of "just use semicolons you weirdos", that example of ending a pipe by calling the topic, and then having a class as the next expression, does seem kinda bad. It's not killer - if the committee decided it was okay and worth being able to have a single-character topic, I def wouldn't block - but it's less than ideal I think. |
21:56 | <jschoi> | nicolo-ribaudo, TabAtkins: I just updated the slide with that ASI example (#6); please take a look and give your feedback on the updated slide when you’re able to. I’m okay with making it an early error and forcing developers to be explicit. Developers who do not want to use semicolons can just parenthesize. |
21:58 | <jschoi> |
…would already be an early error. The anti-semicolon developer must explicitly specify:
…or
|
21:58 | <TabAtkins> | so an early error to have a non-parenthesized decorated class in a pipeline body? works for me |
21:58 | <jschoi> | Great. And I think we should be encouraging developers to keep pipe bodies simple anyway…… |
22:00 | <TabAtkins> | def |
22:10 | <jschoi> | …Come to think of it, I’m uncertain whether ASI would have happened anyway even without a special early error.
I’m…not sure if this fulfills any of the three ASI criteria… |
22:11 | <jschoi> | …But, without ASI, this would be an early error anyway, because then there is no topic reference in the pipe body @(foo)«newline»class C {} . |
22:13 | <rbuckton> | I wonder if records & tuples considered
|
22:15 | <TabAtkins> | too bad [[...]] doesn't work |
22:17 | <jschoi> | Time to bring in non-ASCII brackets. |
22:18 | <jschoi> | https://en.wikipedia.org/wiki/Bracket_(mathematics)#Symbols_for_representing_angle_brackets |
22:18 | <rbuckton> | I'd considered something like
|
22:20 | <rbuckton> | It can be implemented in userland without syntax, though, which lessens its necessity |
22:20 | <jschoi> | I remember that. It’s a cool idea, though, yes, I don’t know if expected usage would be widespread enough to persuade the Committee. I’m reminded of Perl 6’s hyperoperators: «+», «*», etc… |
22:22 | <rbuckton> | It made more sense with F# pipes and PFA. Even more sense with some kind of dot-compose operator for function composition. |
22:22 | <rbuckton> | (i.e., {.} for compose) |
22:23 | <rbuckton> | The design was based on how F# operators work. |
22:24 | <jschoi> | I think maybe the biggest fundamental impedance mismatch, in the end, from adapting those patterns comes from the fact that JS is an n-ary functional language, not a currying unary functional language like Haskell or F#…The PFA syntax was an admirable effort at bridging that difference, though. ~~still hoping to bring F# computation expressions to JS though~~ |
22:27 | <rbuckton> | I still hope to bring PFA back, but I haven't had time to seek out more compelling use cases for it. Maybe even find a less terse syntax than f~(?) to introduce an extra syntax cost to indicate the hidden runtime cost of function allocation. |
22:27 | <rbuckton> | Must go, boarding a plane. Good luck at plenary! |