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 # that probably should be a @
Which slideshow—the pipe one?
21:00
<nicolo-ribaudo>
Yes
21:00
<nicolo-ribaudo>
Where you show ASI
21:00
<jschoi>
It triggered on the topic bikeshed issue
Oh no, what happened, haha…
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>
x |>
  @(foo)
  class C {}

…would already be an early error. The anti-semicolon developer must explicitly specify:

x |> (
  @(foo)
)
class C {}

…or

x |> (
  @(foo)
  class C { x = @; } // The pipe body must have a topic reference!
)
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.

x |> @(foo)
class C {}

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 {{ }} and {[ ]}. The second form would require a cover grammar, but it's visually distinct:

const rec = {{ x: 1, y: 2 }};
const tuple = {[1, 2, 3]};
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 {+}, {-}, etc. for an "operator functions" proposal, though I'm unsure if it would be well received, but it was heavily predicated on PFA:

sum = ar 
  |> map(##, {*} 2)
  |> reduceLeft(##, {+})
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!