Re: Ternary operator patch

[HyperHacker <hyperhacker@...>]

On Sun, Sep 12, 2010 at 15:59, HyperHacker <hyperhacker@gmail.com> wrote:
> 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.
>

Actually, this is already possible (albeit ugly) with a few more characters:
> b=4
> a = ({[true]=1, [false]=2})[b ~= nil]
> print(a)
1

-- 
Sent from my toaster.