Re: Switch/Case statements revisited

[Duck <duck@...>]

> What do you think?

I think (and Steve and I were colleagues once, and hopefully chums still, 
so this is hard to say :-) it mostly sucks.

A case statement which is only syntactic sugar for an equivalent if ... 
elseif ... elseif ... cascade? Why?

The if ... elseif ... elseif ... surely has no visual disadvantages. It's 
equally clear what each elseif is about as it is in a case/switch, and 
actually probably clearer if the overall statement is long, since the 
repeatedly-evaluated part of any conditional subtest is repeated every 
time it's evaluated and used.

I'd have thought that the most useful purpose of a case/switch is to 
indicate both to the programmer and to the compiler than you want to 
evaluate a specific sort of expression once, and then to base a range of 
divergent operations _on that already-calculated expression only_.

Unless there is a specific advantage in semantics (e.g. smaller and 
tighter code) then why bother?

The only reason I dislike if .... elseif ... elseif ... is because when I 
am using it to emulate a C-like switch (compute the condition then 
dispatch on it) I worry that it's repetitious in code and inefficient in 
execution. But in many cases of switches, if performance is that important 
then a pre-initialised table with integer indices and dispatch functions 
for each index -- or some similar compromise -- will solve many efficiency 
issues in the Lua equivalent.

Won;t it?

This case syntactic stuff seems a bit like luaSuper. OK, I can do all this 
extra and clever stuff...at the expense of letting a C++ compiler into my 
LuaLife. Is it worth it? Hmmmmmmmmmmmmmmmmmmmm. No.

Now the bit of your macro stuff I like is try/except.

For all that pcall()/error() is all that a person really needs, it's 
visually ugly in code. Especially when you want to pcall() a method 
invocation (i.e. use of the ':' syntactic marker)...

Which re-re-re-re-revists the "what core things might be in Lua 5.2" 
issue.

I can't resist it:

1. Tables with a special __mode which says to allow nils inside.

2. Tables with a special __mode which says that the array part, if any 
(contiguous N integer indices), is based at zero not one.

3. Run-time setting to instantiate variables at the innermost lexical 
scope ("local") by default, not at global scope.

4. Syntactially clean replacement for pcall()/error(), e.g. try-except or 
try-catch.

Oh, and add:

5. Extend "core and auxiliary" libraries to "core, auxiliary and 
optional." Core and aux to be ANSI-C _only_ (move shared library loading 
to optional). Include a range of popular (if not 100% portable) but 
PUC-endorsed libs in "optional." Start with luasocket and consider 
luathread.