RE: Extending Lua in C, was RE: External modules

["Nick Trout" <ntrout@...>]

> While I agree that Lua is simple and easy to modify, doing so 
> means that you need to reapply or reimplement the 
> modifications everytime the Lua team revs their code.  With 
> other code modules this gets pretty expensive and is to be 
> avoided, but perhaps Lua is simple enough that it doesn't matter.
> 
> Thanks for the code snippets below, looks like there are some 
> interesting ideas there.

Whilst I stated this is what happens I don't like having to reapply
changes either. In fact knowing that versions do change and I'd have to
redo the work actually puts me off doing anything major. There do seem
to be an increasing number of features added by users through patches
though.

On the script side Lua is extremely flexible and is maturing quite
nicely. There is little that you need to change on the scripting side.
However the C internals could be more modular, and perhaps more
"service" based, e.g. GC, memory, type extensions (I know its not the
first time Mr Hook has mentioned mechanisms for customising Lua without
modifying the code base). 

There has been an obvious interest in different types of garbage
collector. Whilst this is an excellent candidate for a modular service,
as has been pointed out, the extent of the GC is most of the code base
and the GC is integral to Luas coding and execution. Perhaps once the
generational collector has been added it could be extended to allow the
facility of choosing between several collectors. If a write barrier is
provided via macros in the code then people could experiment with other
collectors and maybe they'll contribute these to the community (I think
John Belmonte first suggested this).

Type extensions at VM level would be a nice optimisation as well,
perhaps a VM API could be added. I haven't really researched this as
much as I should have but I don't think it would be that difficult to
add user types or extend the "light" user data type so that it you could
do all the overloads that you can do in script.

So, how does this fit in with Luas design philosophy, assuming that
objectives are speed, simplicity and flexibility? Well, you can only go
so fast in script, adding extra VM types and handling them at C/C++
level would be an optimisation and could speed things up. Making Lua
more pick and choose service based would make Lua more flexible and
allow you to tune Lua for your specific environment, e.g. don't care
about resources, embedded environment, real time etc. You can't really
have a language implementation that can cater for everything, you have
to make compromises somewhere, or the strongest direction pulls the
others toward it.

We're already talking about modular cross platform extensions for Lua
client libraries so Lua is getting more flexible on the outside. It
would be nice if this were complimented by a tuneable and extendable
interior where you didn't have to modify the code base for every
application. And, I think it says something that people want to keep
absorbing the continuing work of Lua and not fork it. Keep up the good
work.

Nick