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.
Obviously bad that we did not have a test case that caught this
So thank you for the Fuzzer, @Joshua Warner !
FWIW the fuzzer existed before I joined, but was much much noisier than it is today. I can’t take all the credit.
It seems sensible to me to just disallow a lambda directly in statement position, at least for now
Actually that’ll make returning a function annoying
Hmm
Should have foreseen this…
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
Isn't that the whole point of WSS?
That was an intentional choice to support pizza ops that didn’t have an extra indent
We could make that rule specific to pizza
Could we - if we have less than the minimum indent check for lambda before binop?
I don’t quite follow that
Hold on a sec. I'm working on it
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
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.
does this concern still apply in our new PNC parser?
would be nice to have and
and or
available in userspace DSLs for e.g. SQL
Technically, no
I think it’s potentially confusing still
fair!
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 06 2025 at 12:14 UTC