Re: [PATCH] Jump Tables for Switch/Case and Computed Goto + [RANT] Lua forks are hard

[Paige DePol <lual@...>]

On May 6, 2014, at 2:57 AM, Karel Tuma <kat@lua.cz> wrote:

> Excerpts from Paige DePol's message of 2014-05-06 09:04:04 +0200:
>> The `goto` statement requires you to know the label you wish to jump to at compile time, while the `jumpto` statement resolves the jump destination at run time using a jump table. 
> 
> *Nod*. That is the difference between static and dynamic goto.
> Problem with that is you introduced bloat to language - simply
> extending goto semantics might be preferable under the
> "less is more" doctrine.

Extending the goto statement would still introduce changes to the syntax that would not work under vanilla Lua.

I added the new keywords to properly support the new features. As I am creating a variant of Lua these changes are not bloat to me, they are enhancements to the original syntax. Originally only the keywords for the switch/case were added, once I realised the system was essentially computed gotos I added `jumpto` and jump point labels.

The jump point system is integrated with the goto system. Both use the same list for labels and an extra list is maintained for jumpto statements.


> For example, think about how easier and less invasive is slight
> modification to Lua such as:
> 
> print(a,b,c) -- prints "1 2 3"
> x = "blah"
> a = 1 -- throws compiler error, since 'a' is just
>      -- label identifier, which can be used only as rvalue.
> goto ({ blah: a, durr: b, hurr: d })[x]
> 
> ::a::
>  goto endswitch
> ::b::
>   ... fallthru
> ::c::
>  goto endswitch
> 
> ::endswitch::
> 
> This construct alone, in turn, can do everything you're doing,
> without changing Lua syntax at all (only extending semantics
> of goto).

Well, no, not everything. The switch/case syntactic sugar makes maintaining a complex jumpto much easier, especially with the addition of `continue` and the use of `break` to manage case block control.

Also, you really haven't explained how you would maintain and store the list of goto labels you could jump to at run time. Goto labels are not stored anywhere in the compiled program, nor are they saved in the bytecode anywhere.

Jump points are, when you use `luac -l -l` after applying this patch all jump points are shown in the comments including switch/case statements.


>> That is what I have implemented, albeit currently with a restriction to the block scope. Remember though, this is only version 1 of the patch, and the initial goal was simply switch/case, computed goto syntax was a nice bonus! :)
> 
> I see you're quite devoted to maintaining full-on Lua fork
> - Lunia. In light of that, the patch makes perfect sense,
> and you have my deepest admiration for the devotion to actually
> follow through - use (and maintain) hard fork of Lua.

Indeed I am. I am viewing it as wonderful learning experience that I am having a lot of fun working on.

I decided I wanted to use Lua for my game engine, however, there were a few things I wanted to tweak. Right now I have around ten patches I will be working on adding to GitHub, plus I have list of about 7 more patches to work on.

Some of these changes are simple, like changing ~= to !=, while others are more significant, like my Jump Tables patch. I also have an interesting idea for the lexer and parser, more information once I run some tests! ;)


> You see, I did too at one point maintain bastardized version
> of Lua [1] ("blua" - "bloated lua" set of heavy syntax and
> semantic tweaks, "clua" - C-style syntax incl += etc...).

Funny, one of my patches is adding a version of C++ style comments, changing long string syntax, and setting the integer division operator to backslash.

Another is for the compound operators, and yet another is for letting zero be logically false (as in C, and most languages I've used), but not equal to logical false. The old logic of "a or b" can still be obtained with "a ?? b".


> Problem is, after few years, one realizes there is no futre
> in maintaining an opinionated fork with exactly 3 willing users
> (or thousands of unwilling, if you're Garry's mod).

As long as there is one user, me, I am happy.

I aim to develop all my patches with as clean a Lua codebase as possible. Sometimes some patches will have prerequisites but hopefully not often. The idea is that once Lunia is complete I will have a patch chain that converts vanilla Lua into Lunia. This way people can cherry-pick the features they like... maybe I could even write a web-tool to create custom versions of Lua on the fly! :D 


> If one has desire to invent computer language, I'd say go
> for something new from scratch [2].

Or, tinker with a very nice, very established, very stable and very well proven engine first. I have learned a considerable amount hacking at the Lua codebase. 

Also, note that the switch/case is faster than if/else of 3 or more statements. It is essentially tied at two, and of course one beats switch/case easily. Something like this may be of use to people who have very limited time for scripts to run, but may have a lot of choices to make.


> This is why I am now strong proponent of source code transpilers
> like [3], [4] and many more. At worst, one needs to occasionally
> patch Lua core, usually for sake of performance (ie the transpiler
> can fall back to slower implementation on stock Lua).

I am not sure a transpiler could do the switch/case and jumpto as fast as a native patch, support for programatically changing the program counter is not in vanilla Lua.


> For me, Lua is this scripting CPU instruction set (provides only
> the bare constructs, but does not explode in complexity). And
> transpilers are actual high-level languages :).

I do thank you for your feedback, though the general gist of what you are saying seems to be "I don't like patches". Which isn't so much feedback on my patch as it is a general opinion making interesting conversation! ;)

~pmd~