Re: case statement for Lua

[Norman Ramsey <nr@...>]

 >  >   case x of
 >  >   | "foo" => y = 1
 >  >   | "bar" => y = 2
 >  >   else => y = 99  
 >  >   end
 > 
 > .. and then there was some discussion of the aesthetics. I don't really
 > like the rather cryptic tokens '|' and '=>' either; they're too terse and
 > mathematical-looking for a language that is supposed to be friendly to
 > "casual" users, as Lua is (and all extension languages *should* be). Also,
 > at present, all control tokens are english words and all infix operators
 > are (!isalnum()); it would be a shame to break this consistency.

I would be perfectly happy to use

   case x of
   when "foo" then y = 1 
                   print("x was foo")
   when "bar" then y = 2 
   else y = 99  
   end

Although I find this syntax less appealing, perhaps it is more in the
spirit of Lua.  Then again, since the Lua Masters don't want a case
statement, perhaps this discussion is moot.

 > where:
 > 
 >   <case> ::=  CaseIntroToken <value> ValTerminalToken <statement>   |
 >               DefaultCaseToken <statement>
 > 
 > But as Norman says, it would be much better if the statements were replaced
 > with blocks of statements. 

Agreed.  If you will read the patch carefully, you will see that it does in
fact support blocks of statements, not individual statements.  I've
modified my example above to show a block in one arm.

 > Notice the arbitrary placement of the default case; "else" looks like it
 > *has* to go at the end but "default" looks OK anywhere. 

I think it's (marginally) easier for people reading unfamiliar code to
know instantly that the default case (if any) will be last.

 > In my original post in response to LHF's "wishlist" call, asking for a case
 > construct 

Jeez, I didn't even know there was such a call---I just wanted a case
statement :-)

 > I envisaged it being used when you had, say, >10 choices to cover
 > and being implemented by using the value of the control expression to index 
   a
 > hidden table of anonymous functions, each of which would take no parameters
 > and return nothing.

Two problems:
  - The labels on the case arms have to be compile-time constants,
    instead of arbitrary expressions.  Granted this is almost always
    the case, but I've used the alternate semantics in Icon case statements.
  - More seriously, you require Lua to implement nested functions, or
    else your anonymous functions can't change local variables.

 > This would give a real efficiency gain

I respectfully suggest that we not consider efficiency until we have
measurements of at least one Lua program showing that sequentially
evaluated case statements are a performance bottleneck.

N