lua-users home
lua-l archive

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



I second your second proposal. In fact, I already have token filters doing exactly that (and falling back to select() calls in Lua land).

It seems, ... is the first glimpse of tuples in Lua, and if/when tuples are provided, ... should be just one among them?

Prop 3 could be done (with tables, and functions combined) if/when we get __len to work for tables. No native tuple support would be needed.

-asko


Mark Hamburg kirjoitti 8.8.2007 kello 21:57:

Assorted proposals dealing with assorted issues. Some of this comes down to deciding what the key problem is that needs solving and how much syntactic
help is needed or at least how little hostility is needed.

Proposal 1
----------

* Magic element named '#' gives the length of the table. If not provided, it
gets calculated. For #t, this results in one more lookup for what was
already a search.

* This works just like the old 'n' field except that there is probably no magic shadow table. It's basically just a name change. (If someone wants to argue for the shadow table, I'm not ruling it out but I think we just live
with tables with length being longer.)

* Table construction that includes the token # will include a '#' field:

    t = { #, 1, nil, "baz" }
    print( #t ) -- 3
    print( t[ '#' ] ) -- 3

    t = { #, ... } -- varargs capture

Note that one should get the same value for # no matter where it gets
included in the constructor. This is important because { ..., # } would only
capture the first element of the varargs (if it's even legal).

Proposal 2
----------
Leave tables as they are, but introduce more efficient mechanisms than
select for dealing with varargs. Specifically, allow:

    #... to get the length of the varargs

And

    ...[ i ] to index the varargs

This then allows one to write things like:

    for idx = 1, #... Do
        local v = ...[ idx ]
        -- processing
    end

Proposal 3
----------
Tuples to capture sequences containing nil. This can be done with functions but they are crude because they don't support #tuple and tuple [ idx ]. This can be done with userdata but it gets a bit expensive and leaves open the question of why one needs to bail out to userdata to work around language
"issues".

Mark