Re: Cons, tuple and __slots__ -- a simple mechanism to implement them in Lua
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Cons, tuple and __slots__ -- a simple mechanism to implement them in Lua
- From: Dirk Laurie <dpl@...>
- Date: 2011年9月16日 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[2]
...
> 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[1];
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:
Advantage:
- The patch makes the implementation of tuples easy and efficient.
Any other advantage claimed is a consequence of this one.
Disadvantages:
- Increases the size of userdata by the length of `valuecount`,
four bytes.
- 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[0] 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.
Dirk