Re: Cons, tuple and __slots__ -- a simple mechanism to implement them in Lua

[Xavier Wang <weasley.wx@...>]

2011/9/16 Dirk Laurie <dpl@sun.ac.za>:
> 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.
No, TValue values[1] is not equal with TValue *values, because I put
values *inside* the userdata, i.e. current userdata layout is:
[common header][userdata fields][bytes for userdata...]
and after patching the layout is:
[common header][userdata fields][values...][bytes for userdata]

It means no extra indirect is needed.



>
> 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.
Not always increased, because you can choose "no uservalue", in this
way the size is just the same as the old userdata (yes, the valuecount
has the same size of env).

For the "normal" userdata, you right, it increase four bytes, maybe I
can solve it by some tricks (e.g. use some bits of len or metatable to
indicates there are none or just one values in userdata).


>  - 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.
there are no extra levels of indirection, for struct:

struct foo {
   int a, b, c;
};

has a same layout of:
struct foo {
   int a[3];
};


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

So, the only bad thing is the size, And I will try to solve out it :-)

Thank you very much :)
>
> Dirk
>
>
>