lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 


Hi, Adrian.  Nice seeing you back online!
I have a lot to share about my experiences involving development of luaSub. To me, it seems the road is clear and any Lua+ can now be easily crafted, by anyone. There won't be one, but rather a "cloud" of Lua+'s, like dialects of the same natural language.
I like your pragmatic approach on this; no solution should be done just for itself, but as a means to fill existing real needs. Very little of this actually requires current Lua 5.1.3 to be changed.
The two places where I would see change (in Lua proper) to be necessary are: 

- lua_Number management
LNUM patch does this, giving existing 'lua_Integer' a more full bodied position next to its cousin 'lua_Number'. In a way that is 100% compatible with existing Lua API and scripts. 

- family aware enums

This cannot be efficiently done with current Lua.
Ideally, I would like to see 'tolua' come bundled with Lua itself, since it seems to follow the same minimalistic design goals that Lua has. In my opinion, it could be seen as "the" interfacing tool that's one tier above Lua/C API. And then family aware enums would naturally be handled (automatically) by tolua.
As to most other issues you've presented, luaSub is my answer to the customization needs without patching. Like MetaLua, only it tries to be closer to the existing 'lua' command line tool (now 'luas', with two new flags -s and -o). 

Some of the issues you raise raise my eyebrows:
* Extending the language syntax for non-programmers (who may be in love with Python's whitespace behavior) 

Really?  :)
* Adding automatic support for index-based "string identifiers" (used to localize strings, refer to specific animations, etc)
Why would this need anything in the language itself? Please shed more light.
* 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)
luaSub can be used for this, though such a mod hasn't been implemented by me. I'd just use "local _math_xxx" etc. instead of "math.xxx" Would be transparent to the scripts.
* Adding a specific allocation/management pattern for single-frame temporaries (like intermediate results in vector math calculations)
This was discussed on the list recently, and I don't remember a clear solution having surfaced.
All in all, I very much welcome people to join use and tuning of luaSub. I'll be in charge of the C code if bugs are found. Using it is a piece of cake, and gives Lua the + you are requesting. :) 

-asko




Adrian Perez kirjoitti 21.3.2008 kello 23:48:

Hello, long time lurker first time poster
There seem to be a lot of developers out there using Lua as a configuration/extension scripting language for use in realtime applications like games. We've been evaluating a bunch of languages and Lua has been beating all of them in terms of size, simplicity and execution speed.
In a production environment no language could ever be completely sufficient 'out of the box', and thus the language will need to be manipulated in possibly significant ways. Examples of these sorts of changes:
* Extending the language syntax for non-programmers (who may be in love with Python's whitespace behavior) 

* Seperating LuaNumber into ints/floats for range/performance reasons
* Extending the language syntax for C/C++ programmers (who may be very deeply attached to +=/++/!=)
* Adding automatic support for index-based "string identifiers" (used to localize strings, refer to specific animations, etc)
* 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)
* Adding compile-time replacement of enumerations/flags known in the C/C++ codebase
* Adding a specific allocation/management pattern for single-frame temporaries (like intermediate results in vector math calculations)
The act of extending lua to a particular "lua+" specific to an application or environment can happen in a bunch of ways and seems to be vital to managing the interaction between script and the rest of the application. I suspect most of this is done by directly manipulating the language internals. This approach gives you the most flexibility but ties you pretty tightly to a specific distribution (which is not a huge problem in a short term production environment). There are some interesting tools like MetaLua that allow you to "script" your language extensions, or you can just pre- process the lua script with another lua script before compilation (there are some good examples on the wiki talking about this).
Does anyone have information they could share about their adventures extending the language? 

Thanks,

Adrian