Re: Best Practices for Lua -> "Lua+"?

["Alexander Gladysh" <agladysh@...>]

My humble opinions on your list:

>  * Extending the language syntax for non-programmers (who may be in love with Python's whitespace behavior)

Never. Evil. Non-programmers are not qualified (by definition) to
affect decisions with such heavy consequences.

>  * Seperating LuaNumber into ints/floats for range/performance reasons

Never. Not on embedded platform.

>  * Extending the language syntax for C/C++ programmers (who may be very deeply attached to +=/++/!=)

Never. Evil. Lua is NOT C/C++. The less things would remind of C/C++
the better code would be written.

>  * Adding automatic support for index-based "string identifiers" (used to localize strings, refer to specific animations, etc)

Hmm. I remember a recent post on this subject... Can't remember details though.

>  * Adding compile-time expansion of known types (so rather than a table search for a known interface function you'd inject a constant offset into a function array)

LuaJIT?

>  * Adding compile-time replacement of enumerations/flags known in the C/C++ codebase

Doubtful. Only as a last resort to increase performance. Caching in
local variables / upvalues is benefical.

>  * Adding a specific allocation/management pattern for single-frame temporaries (like intermediate results in vector math calculations)

Thought about it, never had enough time. Still have to try to switch
to some non-default allocator for whole Lua. :-)

So, the bottom line. I'm a conservative PC developer (with respect to
changing the core language at least), and neither my 50KLOC+ of Lua
code for current project (yep, it grows) nor any of my previous ones
have not (yet) reached the point where I would have to optimize it
*that much*.

However, I "adjusted" Lua in two ways:

1. Compiled everything as C++ to simplify writing bindings. (My
project is in C++.) Not a core change, since it is supported by
luaconf.h. However next time I would probably not do that -- I have
enough problems with switching to LuaJIT now (looks like they're on my
side though, still have to investigate that).

2. Added run-time global protection a-la etc/strict.lua, but enforcing
explicit declaration of each global. Not a core change, because done
by the means of the language. Still, I miss an offline validator
(never had time to write one for my specific case -- yes the lack of
time is my problem). But I believe this is not a feature to be built
in the core, but rather a feature for some lint tool.

Alexander.