Stream: ideas

Topic: pizza precedence

Richard Feldman (Mar 29 2023 at 13:13):

so today, this does not compile:

 Str.toUtf8 "Hi there!" |> Str.fromUtf8 == Ok "Hi there!"

Richard Feldman (Mar 29 2023 at 13:14):

the reason is the precedence of |> and ==

Richard Feldman (Mar 29 2023 at 13:15):

Screen-Shot-2023-03-29-at-9.15.30-AM.png

Richard Feldman (Mar 29 2023 at 13:15):

to get this to work, we have to put parens around the part before ==

Richard Feldman (Mar 29 2023 at 13:16):

Screen-Shot-2023-03-29-at-9.15.58-AM.png

Richard Feldman (Mar 29 2023 at 13:18):

I can't think of a use case where this is the behavior we want

Agus Zubiaga (Mar 29 2023 at 13:18):

What about?

positions
|> List.keepIf \pos -> pos.x == 0
|> something

Richard Feldman (Mar 29 2023 at 13:19):

hm, I'd assume in that case the == would be inside the lambda :thinking:

Richard Feldman (Mar 29 2023 at 13:19):

I'll give it a try!

Agus Zubiaga (Mar 29 2023 at 13:21):

Ah ok. Yeah, I can't think of anything else

Richard Feldman (Mar 29 2023 at 13:21):

yeah that still works

Richard Feldman (Mar 29 2023 at 13:21):

(if I change the precedence such that the original example works)

Agus Zubiaga (Mar 29 2023 at 13:24):

For cases where I'd use == to construct a bool to pass as an argument to the piped function, I'd use parens anyway

Agus Zubiaga (Mar 29 2023 at 13:26):

Like in builder pattern:

Button.new
|> Button.disabledIf (count == 0)
|> Button.view

Richard Feldman (Mar 29 2023 at 13:27):

yeah I think the current way, if you use |> and == you always get a type mismatch :sweat_smile:

Richard Feldman (Mar 29 2023 at 13:27):

because you'll always either be trying to give too many arguments to == or else you'll be trying to run a Bool as a function

Agus Zubiaga (Mar 29 2023 at 13:28):

Cool! I like this

Agus Zubiaga (Mar 29 2023 at 13:29):

Would this extend to all comparison operators?

Agus Zubiaga (Mar 29 2023 at 13:35):

I might be missing something, but I think this would work for all infix operators

Richard Feldman (Mar 29 2023 at 13:36):

yeah I think |> should probably just have the highest precedence :thinking:

Agus Zubiaga (Mar 29 2023 at 13:59):

Except for unary operators, right? I think -a |> b should mean (-a) |> b and not -(a |> b)

Agus Zubiaga (Mar 29 2023 at 14:00):

That might always be the case when mixing unary and infix. Not sure how the parser works.

Richard Feldman (Mar 29 2023 at 14:03):

oh sure

Richard Feldman (Mar 29 2023 at 14:03):

yeah I'm just talking about infix operators here

Agus Zubiaga (Mar 29 2023 at 14:09):

Cool cool

Brendan Hansknecht (Mar 30 2023 at 04:34):

Crazy question. With the change in precedence, would this work:

a
|> SomeTransform
|> == SomeResult

Brendan Hansknecht (Mar 30 2023 at 04:35):

Note, ==could theoretically be any other infix operator.

Joshua Warner (Mar 30 2023 at 18:11):

The fact that the |> parts are on multiple lines, and the == is on the same line, make that read really strangly to me

Joshua Warner (Mar 30 2023 at 18:16):

If we want to reduce the precedence, IMO that really only makes sense if we start formatting it differently

Joshua Warner (Mar 30 2023 at 18:18):

Right now, if you have a '+' operator somewhere in the middle of a pizza chain (with no parens), you'll get an error that one of the elements of that chain is not a function call (I think / assume?). If we just naively reduce the precedence, that + operator will be at the root of the tree - which will IMO be very unintuitive with the normal formatting

Richard Feldman (Mar 30 2023 at 20:08):

yeah I don't think |> == ought to work :big_smile:

Richard Feldman (Mar 30 2023 at 20:13):

in genearal I don't think we should allow multiple infix operators in a row

Kevin Gillette (Apr 02 2023 at 15:36):

x < y < z can be pretty nice in some languages (as an equivalence for x < y && y < z), but it admittedly doesn't come up very often, and there are usually additional rules to prevent someone from writing out-of-order expressions like x > y < z

Last updated: Jun 16 2026 at 16:19 UTC