lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Thank you for Doug, and other Lua Hackers.

At first, I found that my patch is not complete.  It will mis-compile the code with local variable.  My patch will compile following code as returns always 'a'.  Could someone please correct my mistake, or don't use my patch.

function f(a)
  return if a then g(a) else a
end

One of the reason I want to add 'real' ternary operator is to make convenience for the old C programmers.  They always complain that Lua lacks blah blah.  And/or technique is well, but they may forget the care for second parameter.  Functional programming is lovely (I just learned Haskell last year!), but they don't need it today.

Thank you
Ryota Hirose

2010/9/13 Doug Rogers <douglua@dkrogers.com>
Enrico Tassi wrote:
On Fri, Sep 10, 2010 at 06:01:28PM -0300, Roberto Ierusalimschy wrote:
On the other hand, a syntax with "end" is cumbersome.
I find it nice instead, it just looks like if the if-then-else-end
construct had been promoted from the statement class to the _expression_'s one.
Maybe I'm too biased by functional languages, but I very often type, by
mistake, "z = if b then x else y end"...
Cheers, and +1 for that "feature".

Another +1. I too find myself typing it. I cannot train my brain to stop! I have a small preference for requiring 'end', just for consistency with the statement version.

The 'x and y or z' construct is not elegant for this type of _expression_, though I do find myself using 'x = x or default' for function arguments.

As you know when saying it *just looks like* the statement has been promoted to _expression_, adding if-then-else-end to the 'exp' element in http://www.lua.org/manual/5.1/manual.html#8 does not allow it to be removed from the 'stat' section. Lua currently does not allow "empty" expressions as statements; the expressions have to go somewhere.

But I sometimes daydream about making all of Lua's statements into expressions, removing 'stat' altogether. Lua would then be a functional language with a concise imperative syntax, easily learned by those coming from such a background. We could add an optional argument to 'break'. We could choose natural return value(s) of 'for-do-end' or 'while-do-end'. We could do all the Lispy things that some of us love to do. To be fair, Lua supports most such things already. And with words, not operators, David Kastrup couldn't complain about line noise! :)

So thanks, Ryota Hirose.

Your patch works well for me. It might compel me to add it to my base Lua installation. It also serves as a good template for playing with other statements-as-functions. I can see expr() in lparser.c becoming a switch statement on the next token. Can you say "eval"?

Doug