[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Cons, tuple and __slots__ -- a simple mechanism to implement them in Lua
- From: Dirk Laurie <dpl@...>
- Date: Fri, 16 Sep 2011 07:48:19 +0200
On Fri, Sep 16, 2011 at 04:21:58AM +0200, Xavier Wang wrote:
> patch-ev is a very simple and powerful improve for Lua. It fills the
> space between simple type such as number and string and the only
> complex type table.
Your suggestion is to change the implementation of userdata so that the
following tasks become easy and efficient:
> multi user values can use to implement tuples
> to implement a typed-tuple (or __slots__ in Python) also very easy
> But use table to implement cons of lisp is wasteful, so I think about
> a more lightweight way to do it.
> it pushs me to think about how to implement a light weight but generic
> container in Lua.
The change is visible at the level of the C API but not at the level of
Lua code except via modules exploiting the enhanced API.
The heart of the patch is in the struct used to represent userdata.
- struct Table *env;
+ size_t valuecount; /* number of extra values */
+ TValue values;
I.e. instead of a table, userdata now has a fixed-length array of TValue
(the last line is equivalent to `TValue *values` except if your compiler
has a range-checking option). No functionality is lost, since one can
always use an array containing exactly one element, a table.
So far so good.
You then summarize advantages and disadvantages:
> the advantage of ev:
> - don't change any of existing interface of Lua C-API.
> - don't change any semantics of Lua.
> - much faster and smaller than table.
> - fills the space of the huge data structure and the simple data type.
> the disadvantage of ev:
> - only support fixed length of multi user values (that is, you can not
> change the size of values after allocation a new userdata).
> - need patch to core of Lua.
> - need the approve of Roberto :(
That last point is an advantage, not a disadvantage. :-)
My take on the advantages and disadvantages is this: the "don't change"
and "need patch" aply not only to this suggestion, but to just about
any suggestion affecting implementation. So I would say:
- The patch makes the implementation of tuples easy and efficient.
Any other advantage claimed is a consequence of this one.
- Increases the size of userdata by the length of `valuecount`,
- Clumsy when in fact the userdata wraps just one table, i.e. all
present applications of userdata. There is an extra level of
indirection and one needs to test that values is a table.
The disadvantages apply to all userdata. I.e. the patch will in general
be wasteful except when enough use is made of tuples.
So: sometimes good, sometimes bad.