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

[Luiz Henrique de Figueiredo <lhf@...>]

>I don't like having to reapply changes either.

I understand and sympathize with people feeling weary at having to recode
their changes of the internals of Lua each time a new version comes out. While
we do make every effort to maintain compatibility of Lua code, it's very hard,
if not impossible, to maintain any kind of code-level compatibility for the
core implementation. Any attempt at this could compromise our goals of size
and speed. The prime example is the VM, which is an implementation tool, not
an iron-cast concept, and so we feel free to change it if this will make Lua
faster and smaller.

What does remain more or less stable is the inter-module API, that is, those
lua[A-Z]_ functions. If you come up with a re-implementation of the services
of a module (usually a handful of functions) then you can just plug it
right into the code. The prime example is lmem.c which only really exports
luaM_realloc, and so that's just one function to rewrite. In this case, there
is a macro hook for convenience.

The core is somewhat modular. At least, the major parts of it are. The really
modular parts are the memory allocator and the lexer-parser-code-generator,
which makes it easy to create a core without the parser (a definite plus for
small systems) while still being able to build luac.

The GC module is being rewritten and the rest of the core will use macros
that can be redefined if a different GC module is used.

>Type extensions at VM level would be a nice optimisation as well,

This I think is the hardest part, even if at first sight easy. I don't really
see a need for this: userdata are supposed to do this reasonably efficiently.

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

Yes, we're keeping this in mind, but no promises...

>And, I think it says something that people want to keep absorbing the
>continuing work of Lua and not fork it.

Yes, this is an amazing community! Thank you all for your support!
--lhf