lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

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