Re: Switch/Case statements revisited

["Tim Kelly" <gtkelly@...>]

David Given wrote:

> Yes, but you don't want to sacrifice speed unnecessarily. The advantage
> of the above syntax is that it's entirely obvious to the compiler when
> you're matching against a specific item (with <expr> [, <expr>...] then)
> or against an expression (with <varname> if). This makes it trivial for,
> say, the JIT to construct real jump tables.

Hence my suggestion that the conditionals be evaluated as an index to the
block of code to be executed.  If the "In Case Of..end" block is parsed
for conditionals prior to compilation/execution, a jump table can be
constructed.

However, more importantly, if the jump table is _not_ compiled, the "In
Case Of" conditional can be extended to include evaluation of function
returns

@(CheckOtherConditionsExist(k))

This defers executing the function CheckOtherConditionsExist until the
preceeding conditionals all evaluate to false.  That creates an
opportunity for the conditional arguments be dynamically generated.

> It also allows you to define different ordering semantics. If you
> specify that the expressions in a match can be evaluated in any order,
> and that it's the responsibility of the user to make sure that they're
> not ambiguous, it makes the compiler's job much easier.

Ultimately, though, programming languages are to make the programmer's job
easier, not the compiler's.

> ...is almost identical to:
>
> if (10 <= k) and (k <= 11) then return 1
> elseif (k == 12) then return 2
> elseif (z == 0) then return 0
> elseif ((k == i) and (13 <= i) and (i <= 16) then return 4
> else return 99
> end

For such a simple example, yes, they are identical.  However, add twenty
or thirty lines of code in between elseif statements (including nested
if-then-elseif statements to evaluate intermediate conditionals, like z
not equal to 0 if k is great than 12) and the benefit to the programmer of
a clear demarcation becomes quite obvious.

> (I should also point out that 10 <= k <= 11, while nice for the user, is
> an utter nightmare for the grammar --- unless you declare an entirely
> new syntax specifically for use in this situation, it can't decide
> whether you mean a range check or the expression (10 <= k) <= 11...
> which is completely legal. Although is likely to produce a run-time
> error.)

Yep, that should have read

@((k>=10) || (k<=11))

>> Also, Asko's version
>> didn't match David Given's version, as his version requires (as I read
>> it)
>> for k to equal i as well as i be between 13 and 16, instead of k being
>> between 13 and 16.
>
> Yeah, what I meant was that i would be a new local variable containing
> the value of k in whose scope the if statement was evaluated.

That strikes me as much more difficult for a compiler to recognize than
variable arguments, wherein the process of evaluating a conditional
creates a local variable scoped only to the conditional itself.  Now, in
the event that Lua can already handle such a situation, I would think such
a mechanism could also evaluate the results of a function evaluated only
within the conditional.

tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com


"Anything war can do, peace can do better."  -- Bishop Desmond Tutu