Re: Proposal for a new construct in Lua

[Michael Rose <michael.h.rose@...>]

I attached an update (V2) for my proposed jump table patch with the
following three changes:

* Every entry has now an implicit 'break' statement at the end unless
  an 'and' keyword is placed between two entries. E.g.
    jump chr in "0z" do
       "aeiou"     do print("vocal")        end   and
       "a" .. "z"  do print("lower letter") end
       "0" .. "9"  do print("digit")        end   and
       do print("no lower letter") end
    end
  works now as expected. The 'break' statement is still allowed though
  to exit the whole jump table construct whereever it is desired.
* Equal indices between two entries are now accepted and silently
  ignored. Therefore in the example above, the vocals can be part
  of the range specification "a" .. "z". The first occurrence indicates
  the entry clause to be jumped to.
* The local variable is now optional. Therefore a formulation like
    jmp chr = str:byte(k) in ... do
  can now be abbreviated as
    jmp str:byte(k) in ... do
  if the local variable is not needed in the entry clauses.
  I still find it useful to have the option of such a variable, which
  can be used to discriminate subcases in a multiple entry clause.

Am 14.05.2011 21:49, schrieb Gaspard Bucher:
> ...
> 
> I tried to map the C minor example to Michael's proposition:
> 
> jump state do
>   'm2' do
>     jump token do
>       2 do play(36) break end
>       5 do play(31) break end
>       6 do play(38); state = 'm22' break end
>       1 do play(37) break end
>     end
>   end
>   
>   do
>     # Default actions
>     jump token do
>       200 do state = 'm2' end
>     end
>   end
> end
> 
> I don't like the need for the "break" everywhere (I hate it in C switch)
> and since the common idiom is to "break" why not remove it and use

see changed proposal at the beginning...
I also prefer the new default behaviour, but a 'continue' statement  as
you suggested whould be probably problematic, because the expected
meaning of such a keyword is quite different to the fall through thing.

> "continue" when we need to continue evaluating rules ? I also do not
> understand the need for the 'val = xxx in "yyy"' construct. Why not
> simply use "jump fmt:byte(i) do" ?

The local variable "val = ..." can now be suppressed, see changed
proposal. But the 'in <rng>,...' part is necessary due to the way, this
construct is best implementable in the Lua compiler. The compiler is
a one pass compiler. Therefore it is most appropriate to have a jump
table in the opcode part at the beginning of the construct before the
entry clauses are compiled to bytecode. A relocation of entry clause
bytecode to correct a jump table size is not easily done in the current
Lua compiler.
The alternative would be to put the jump table after the entry clauses.
This would be possible, but the compiler has to manage the open branches
in extra dynamic arrays. The final code has an extra jump
statement from the start of the construct to the jump table opcode.
But even worse, all jumps from the jump table are backward jumps to the
entry clauses. As far as i know the implementation of backward jumps can
have bad impact on the trace compiler of Luajit. In order that this
construct can as easily be integrated into Luajit than into Lua, this
should be avoided. And I think to specify the ranges in front does not
hurt. One could list all non-default entry indices or just the bare
minimum and maximum ones (as done in the example), because the compiler
uses the ranges after 'in' only to calculate the offset and size of the
jump table in the opcode area.
Specifying all ascii values in string form makes the code independent
from the ascii codes. Specifying only the minimum and maximum indices is
shorter to write. If jump table size doesn't matter, for characters the
range 0,255 can be given alternatively. In any case if the entry indices
specified in front of each clause are not in the 'in' range, the
compiler will throw an error.

> 
> Gaspard
> 
> [1] http://gaspardbuma.org/fr/post400.html
> 

Regards,

Michael