upvote

points

by 3eb7988a166317 hours ago |
comments
upvoteby demilicious17 hours ago|
next
[-]
That’s why “if” should just be an expression
reply
upvoteby matheusmoreira17 hours ago|
parent|
next
[-]
This is the best answer in my opinion. Ternary is just sugar for an expressive if. LuaJIT seems to be focusing on adding new syntax though, maintainer might not be amenable to updating existing semantics.
reply
upvoteby boomlinde3 hours ago|
parent|
next
[-]
I imagine that if/if-else as expressions and then necessarily their bodies as expressions would entail a much more fundamental change to the language. You then have to think of a way for the bodies to indicate a result. That, or you have to make a special case for if/else sequences where the bodies are bare expressions, in which case you've just invented the ternary operator.

Zig and Rust have addressed the problem of how the result of a block expression should be presented, but neither solution seems particularly satisfying to me.

In Rust, blocks may end with an expression, giving them a non-void result. But a block may also end in a statement, the only difference being that the statement ends in a semicolon, in which case the expression still has the void result, and I think that semicolon being the only difference makes it hard to scan at a glance where values come from.

In Zig, blocks may give non-void results by `break`ing out of them with an expression. But break normally ignores blocks and break out of loops only, so to break out of blocks you have to provide a label for it and give that when you break so as to break out of the named block and not the outer loop, e.g. `const x = label: { break :label 35; }`. That creates a problem of one of the most difficult classes in software engineering: naming things. Ideally I think `break` from a block should have its own keyword, e.g. `const x = { give 35; }`

reply
upvoteby wavemode16 hours ago|
parent|
prev|
[-]
I don't think if-expressions have to affect existing semantics. Basically, in the parser you would have two different kinds of AST nodes, one for when the `if` keyword is encountered in statement position and another for when it's encountered in expression position.

Right now, `if` in expression position is just a syntax error ("unexpected symbol")

reply
upvoteby Joker_vD14 hours ago|
parent|
[-]
Well, I believe there could be some complications with parsing related to the fact that Lua grammar doesn't really requires semicolons between the statements.

But other than that, yeah, detecting "if" in the expression position is pretty unambiguous. No idea why most languages went with "cond-expr ? then-expr : else-expr" bracketed syntax instead.

reply
upvoteby _flux13 hours ago|
parent|
[-]
Surely the most likely explanation is familiary from C?

But e.g. ml-family languages (like OCaml, F#, Haskell) and Rust just have the *if* expression that has a non-void value. If your language accepts expressions as statements (most do?), then I think that should just be compatible out of the box.

reply
upvoteby Joker_vD12 hours ago|
parent|
[-]
Yes, but why C had that syntax? Oh, right, because it didn't use if-then[-else]-end for the conditional statement, and reusing if(cond)[-else] with prohibited braces would be awkward.

Oh, and Lua most famously does not accept expressions as statements. Which, now that I think of it, would actually evade most of the parsing complications.

reply
upvoteby rirze3 hours ago|
parent|
prev|
next
[-]
As long as the language supports lazy evaluation and short-circuiting through expressions, then great.
reply
upvoteby NuclearPM15 hours ago|
parent|
prev|
[-]
Yep. Everything should be.
reply
upvoteby 20198417 hours ago|
prev|
next
[-]
Lua basically already has ternary operators anyway since "and" and "or" short circuit. I also don't see the need of adding additional syntax for it.

  local x = condition ? value_a : value b
  local x = condition and value_a or value_b
reply
upvoteby nmz1 hours ago|
parent|
next
[-]
No, not basically, it simply doesn't have them, Ternary means three as in it operates on 3 operands, and/or operates on 2 operands. They are also not equivalent.

   x = a ? b : c # x is b, same as you would if a {x=b} else {x=c}
lua and/or

    a,b,c = true, 1, 2
    x = a and b or c -- x is b


    a,b,c = true, false, 2
    x = a and b or c -- x is c
The or is dependent on its previous operand, so b will return false and skips to c, even if you meant for it to be b. you must use an if then else. However, you can have more than a ternary, if there is no need for short-circuit evaluation, as in, any of the operand is not a function CALL like c(), and you want to remain inside an expression, then you can do this instead

select (select is a native C function, this is faster than the table creation below)

    x = select(a and 1 or 2, b, c)
table creation/selection

    x = ({false,2})[a and 1 or 2]
of course, doing something like

   local x; if a then x=b else x=c end
does not look so bad
reply
upvoteby matheusmoreira17 hours ago|
parent|
prev|
next
[-]
> The classic Lua idiom a and b or c has a pitfall when b is nil or false: then c is returned, even when a is truthy.

> E.g. true and false or 42 returns 42, whereas true ? false : 42 returns the (expected) false.

reply
upvoteby 4 hours ago|
parent|
prev|
[-]
deleted
reply
upvoteby Gualdrapo17 hours ago|
prev|
next
[-]
I guess for the JS case it makes sense to be able to shave a few characters for file shrinking purposes, but generally I'm more biased to code clarity and "self-explainability"
reply
upvoteby NuclearPM15 hours ago|
parent|
[-]
That’s what compression is for.
reply
upvoteby hiccuphippo17 hours ago|
prev|
next
[-]
I find it most useful in languages that have non-mutable variables and you want to avoid a mutable variable or an extra function when the value comes from a simple condition.
reply
upvoteby otikik4 hours ago|
prev|
[-]
In Lua (and LuaJIT) you can already use `and` and `or`:

    local x = y and y + 1 or 0
The knuckle heads are already using them everywhere.
reply