Stream: compiler development

Topic: New lambda syntax / BinOp contention

Anthony Bullard (Jan 15 2025 at 22:31):

The new lambda syntax |_| ... has an issue

When parsing a term, we had to peek before trying to parse this to make sure we don't try to consume the || and |> operators as part of the lambda args. That was fine.

But now, because of the way we parse exprs due to WSA, we kind of just eat all of the possible exprs in a series and then figure it out later. This includes those same BinOps, which are looked at first in that case. This causes a new lambda in a "statement" position to fail to parse if after another expression.

Anthony Bullard (Jan 15 2025 at 22:34):

Obviously bad that we did not have a test case that caught this

Anthony Bullard (Jan 15 2025 at 22:34):

So thank you for the Fuzzer, @Joshua Warner !

Joshua Warner (Jan 15 2025 at 22:35):

FWIW the fuzzer existed before I joined, but was much much noisier than it is today. I can’t take all the credit.

Joshua Warner (Jan 15 2025 at 22:37):

It seems sensible to me to just disallow a lambda directly in statement position, at least for now

Joshua Warner (Jan 15 2025 at 22:37):

Actually that’ll make returning a function annoying

Joshua Warner (Jan 15 2025 at 22:37):

Hmm

Joshua Warner (Jan 15 2025 at 22:39):

Should have foreseen this…

Anthony Bullard (Jan 15 2025 at 22:40):

I just don't understand why it tries to parse this as an op when it doesn't meet the min_indent to continue the preceding statement

Anthony Bullard (Jan 15 2025 at 22:41):

Isn't that the whole point of WSS?

Joshua Warner (Jan 15 2025 at 22:41):

That was an intentional choice to support pizza ops that didn’t have an extra indent

Joshua Warner (Jan 15 2025 at 22:42):

We could make that rule specific to pizza

Anthony Bullard (Jan 15 2025 at 22:42):

Could we - if we have less than the minimum indent check for lambda before binop?

Joshua Warner (Jan 15 2025 at 22:43):

I don’t quite follow that

Anthony Bullard (Jan 15 2025 at 22:48):

Hold on a sec. I'm working on it

Anthony Bullard (Jan 15 2025 at 23:22):

Can't really do it. It's happening in parse_stmt_operator_chain, which returns a single statement, but I would either have to backtrack a LOT, or return multiple statements

Brendan Hansknecht (Jan 16 2025 at 00:04):

Joshua Warner said:

FWIW the fuzzer existed before I joined, but was much much noisier than it is today. I can’t take all the credit.

I think I set up the initial fuzzer, but it was left unloved and unrun for a long time.

Richard Feldman (Feb 12 2025 at 16:52):

does this concern still apply in our new PNC parser?

Richard Feldman (Feb 12 2025 at 16:53):

would be nice to have and and or available in userspace DSLs for e.g. SQL

Joshua Warner (Feb 12 2025 at 16:55):

Technically, no

Joshua Warner (Feb 12 2025 at 16:55):

I think it’s potentially confusing still

Richard Feldman (Feb 12 2025 at 17:02):

fair!

Richard Feldman (Feb 12 2025 at 17:06):

although if this works unambiguously, we could parse it and give a warning like "in Roc we use and instead of &&" and have the formatter fix it for you

Last updated: Jul 26 2025 at 12:14 UTC