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

[Karel Tuma <kat@...>]

Excerpts from Paige DePol's message of 2014-05-06 09:04:04 +0200:
> 
> I have added an entirely new feature to Lua, while adhering to the same coding style as the original source. I believe I have done so in as many lines as were required, with as little waste as possible. If you can make the code smaller and/or better please share the patch, I am always looking for opportunities to learn! 
> 

Your code itself is fairly decent - Now brace yourself,
I'll be ranting about the gist of _why_ I don't like it.

> 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.

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).

> 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.

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...).

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).

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

Maybe I'm just old and bitter, but my perception is just
that it takes so much more for computer language to survive
than just being forked mod of existing language, or worse,
shoving it someone's throat (like aforementioned Garry's mod).

Lua itself is *trivial* to extend simply because it is so small.
However, rarely is there strong case for such extensions, and
in case the users/scripts are forced to use it, might be genuinely
harmful.

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).

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 :).

[1] http://lua-users.org/lists/lua-l/2006-10/msg00624.html
[2] http://fll.presidentbeef.com/
[3] https://github.com/quaker66/luacy
[4] https://github.com/leafo/moonscript
[n] .. I'm sure there are dozens of Lua dialect transpilers