Re: Ternary operator patch

[HyperHacker <hyperhacker@...>]

On Sun, Sep 12, 2010 at 15:03, Doug Rogers <douglua@dkrogers.com> wrote:
> 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
>
>
>

David isn't the only one concerned about line noise. I like the idea,
but wouldn't mind seeing it with words instead of punctuation. I'm not
sure which words, though. Overloading if/else looks ugly.

I guess you could hack up a construct like:
a = {true=1, false=2}[b ~= nil]
(i.e. allow tables themselves, rather than only references to them, to
be indexed), but then you have the overhead of creating a throwaway
table, and having to specify true/false as the keys bloats it a bit.
(Though you could have it use 1 for true and 2 for false, reducing the
syntax bloat.)

-- 
Sent from my toaster.