rfcs
rfcs copied to clipboard
proposal syntax else ... then for else keyword in conditional branches
examples in tutorial
if a == b then
env.out.print("they are the same")
else
if a > b then
env.out.print("a is bigger")
else
env.out.print("b bigger")
end
end
limited by set pattern in old school
if a == b then
env.out.print("they are the same")
elseif a > b then
env.out.print("a is bigger")
else
env.out.print("b bigger")
end
just use "else ... then" instead of "elseif ... then"
if a == b then
env.out.print("they are the same")
else a > b then
env.out.print("a is bigger")
else
env.out.print("b bigger")
end
And it is ok in expressions
x = 1 + if lots then 100 else afew then 10 else 2 end
And there is almost no additional cost for parsing.
Without heavy justification in an RFC, I would be against this proposal. I would advise anyone writing an RFC for this to spend a good deal of time explaining why this is better than what currently exists as this adds nothing semantically that isn't already in the language.
What's the value/improvement that this would bring?
What's the value/improvement that this would bring?
Removing a keyword elseif
for a simpler language?
While simple is better, I don't know that everyone would agree that removing the keyword elseif
would decrease complexity, rather than increase it.
I am not in favour of this change; I think that else ... then
would be more confusing than elseif
.
Even if we were to agree it is both simpler and better in absolute terms, it needs to provide enough value to justify overcoming the friction of a widely-breaking change.
If the value it provides is marginal or just notional, but not significant in the sense of providing meaningful/substantial value to users of Pony, then it's not worth the breaking change.
Dropping in to say I am also not in favor of this. Also here to add that ifelse
would have to be removed from ifdef ... ifelse... else ... end
for it to be fully removed.
@SeanTAllen also mentioned in today's sync that the parser is currently written to require no lookahead, and this would potentially break that current invariant.
@jasoncarr0 also mentioned that human parsers also have the same problem with lookahead :wink:
Though not clearly documented in the tutorial, one can simulate this syntax with pattern matching using guards, like:
actor Main
new create(env: Env) =>
let x: USize = 123
match x
| if x < 50 => env.out.print("< 50")
| if x < 100 => env.out.print("< 100")
| if x < 200 => env.out.print("< 200")
else env.out.print("= 100")
end