The `|>` operator can cause parsing errors where normal function calls do not about numbat HOT 6 OPEN

A smaller example with a similar problem:

>>> if true then 1 |> id else 0
error: while parsing
  ┌─ <input:11>:1:16
  │
1 │ if true then 1 |> id else 0
  │                ^^ Expected 'else' in if-then-else condition

The problem is that |> has lower precedence than if … then … else (https://numbat.dev/doc/operations.html). It can be fixed using parens:

>>> if true then (1 |> id) else 0

But maybe precedence should be changed to allow for this? I guess if we would do that, it would prevent us from doing things like

if … then … else … |> function

and we would have to put the conditional into parens:

(if … then … else …) |> function

which defeats the initial purpose of this operator (that you can always just add it at the end of a line to do an additional function call)

from numbat.

Unrelated: I'm excited about this unit_list feature!

from numbat.

The problem is that |> has lower precedence than if … then … else

Oh of course, I completely forgot about that. I'm not sure of which is better, but perhaps a terminating token to the if-else expression would solve some of the problem? My thinking is that the then clause is already delimited by the else, making it a logical unit to scope as if in parentheses. If the else clause could be delimited as well it would also have an easy to parse scope. It does bring other challenges but it would disambiguate a pipe after the whole statement as if it's after the delimiter it would apply to the whole if-else expression while if inside it applies to only that scope. My main argument against this approach would probably be changing if-else expressions would become ugly or reintroduce ambiguity.
For good measure here is an example syntax for the idea:

if true 
then 1.5m |> floor_in(m) 
else 1.5m |> ceil_in(m)
end

# equivalent to
if (true)
then ( 1.5m |> floor_in(m) )
else ( 1.5m |> ceil_in(m) )
end

# the problem with chaining:
if i < 0
then "negative"
else 
  if i > 0
  then "positive"
  else "zero"
  end
end

from numbat.

Unrelated: I'm excited about this unit_list feature!

I really liked the idea of it when I read about it, so I'm excited to try my hand at it!

from numbat.

I'm not sure of which is better, but perhaps a terminating token to the if-else expression would solve some of the problem? My thinking is that the then clause is already delimited by the else, making it a logical unit to scope as if in parentheses. If the else clause could be delimited as well it would also have an easy to parse scope. It does bring other challenges but it would disambiguate a pipe after the whole statement as if it's after the delimiter it would apply to the whole if-else expression while if inside it applies to only that scope.

I think that reasoning is correct.

if-else expressions would become ugly

Indeed :-/

# the problem with chaining:

what do you mean by that?

from numbat.

# the problem with chaining:

what do you mean by that?

I meant that making a chain of if-else expression would no longer be possible without nesting them.

I've had an idea about this. Could the syntax of the if-else be extended? To my understanding the current syntax is something like the following.

IfElse = "if" Cond "then" Expr "else" Expr 

What if chaining was an actual part of the syntax and all chains had to end with a terminating token. Something like the following.

IfElse = "if" Cond "then" Expr "else" Expr  ; Regular if-then-else
IfElseChain = 1*IfElse "end" ; A chain of one or more if-then-else's terminated with a single "end" token

I'm thinking this allows for an optional end token for the normal case that could be used to make the parsing of the pipe operator unambiguous and making the nesting of if-then-else chains easier to determine. As far as I can see it would allow for the current syntax in all cases but enable additional uses without the need for parentheses or many ugly terminating tokens.

Disclaimer: I do not really understand the current implementation of the expressions. I have never used Rust and can't really gauge how big of an undertaking this would be, so if it is a larger change then I don't mind the parentheses that much, but would probably write a paragraph about it in the documentation.

from numbat.