Re: On lua5 and embedding

[paul@...]

On Wed, Jan 29, 2003 at 08:11:49AM -0200, Luiz Henrique de Figueiredo wrote:
> 
> Right. But that was a request by the community: many people want simply to
> store C pointers in Lua with as little overhead as possible to retrieve them
> later. These C pointers point to areas that are managed by the application abd
> they don't care whether there are references to it in Lua or not (and so need
> not be told about GC for them).

Yes, I certainly appreciate the design of light-weight userdata, it is
very clean for its purpose.
 
> By definition, that's what "heavy-weight" userdata is. Or is your complaint
> about the use of Lua's memory allocation? You can always compile Lua to use
> your own memory allocation method.

I meant pointers returned from some other library, of which the programmer
has no control over their memory allocation, and yet wants to leverage on 
Lua's GC for management.
 
> >I can no longer define a GC method for pure C pointers. 
> 
> You can "box" them inside a heavy userdata. C pointers that do not need GC
> methods can be stored in light userdata.

"boxing" is kind of different from the in Lua4, since uniqueness isn't
preserved. Using weak tables may help to nail down the problem, but not
really ease the burden on programmers since now there is an extra table 
to be either "globally" referenced or "passed around" when needed.

BTW, thanks for the links. I wasn't aware of the lua_(un)boxpointer macros.
 
> >When it occurred to me almost impossible to convert my program to
> >Lua5, I'd still stick with Lua4 for now.
> 
> Why impossible? The move to Lua 5 is meant to gain more users not lose
> them! :-( Please, tell us how we can help.

I shouldn't have said "impossible", but the trouble with my program is
in its sheer size. Unless there is a painless migration by a wrapper 
interface "identical" to Lua4's tag mechanism, I am quite reluctant to
make the decision.

And even with such a wrapper in hand, the memory/performance gain isn't
very appealing, given the extra overhead of 1) the box itself; 2) weaktables
that map all boxed value to unboxed value; 3) metatable for every tag.
The overhead could be quite serious for memory management under a 
runtime situation where lots of userdata is created/freed every second.

Unless, of course, if Lua6 delivers the progressive GC promise. That'll
be the ultimate reason for porting all my Lua4 applications over ;-)

> It worries me that some people seem to have a negative impression of Lua 5
> so near to it being officially released. Someone even said that we have
> "seriously damaged Lua functionality"! Sure, Lua 5 is different from Lua 4.
> The metamethod scheme is not the same as the tagmethod scheme, but it is
> simpler and more flexible, even if sometimes you have to use proxy tables
> for doing some stuff that was easy in Lua 4. Lua 5 was the outcome of a long
> sequence of work versions of Lua 4.1 and has gone through alpha and now beta
> stages. I'd think major design flaws would be found by now :-(

The problem I've raised is certainly not a design flaw, but it does
pose some resistence for people to port old apps onto new Lua version,
especially which the old one works just fine. I'll consider adopting 
Lua5 in new porgrams by adjusting the design to take advantage of Lua5's
own merits. 

Regards,
.paul.