5.1/5,2 compatibility
Luislang
steve donovan
> Should we aim at 5.1 compatibility in Project Vanity?
Good question. Lua 5.2 is more extension-friendly in the sense that
tables respect __len, __ipairs and in fact will probably respect __gc
as well. The Lua 5.1 equivalents would be somewhat forced.
But 5.1 is not going anywhere in a hurry. As long as LuaJIT remains a
Lua 5.1 implementation, then the smart people are not going to want to
move on - quite apart from the ABI breaking and the usual
transitionary mess. To be honest, Lua 5.2 is an awkward release
because it breaks enough to be a nuisance but doesn't add enough to
make people want to take the trouble to embrace it.
steve d.
Frank Siebenlist
I'm using Ansca's Corona which has a crippled Lua 5.1 baked-in.
-Frank.
Dirk Laurie
> Some of us have no choice as the version is determined by the framework we
> use for our work.
>
> I'm using Ansca's Corona which has a crippled Lua 5.1 baked-in.
>
Well, your contribution to the coding project can be to add backward
compatibility :-)
I append a first version of vanity.lua. At this stage, I've implemented
only 'list'. In true OSS spirit, everybody is welcome to take it apart
and post a revised version. But please, look at the bugs and to-do's.
Some of those are beyond my powers, so they will stay there unless one
of you can fix them.
Start up Lua 5.2 and enter:
require"vanity"
vanity_test()
Dirk
steve donovan
> I append a first version of vanity.lua. At this stage, I've implemented
> only 'list'.
Oops, attachment didn't get through. Since Google Groups doesn't have
pages anymore, we need a scratchpad.
Any suggestions?
I've updated my 'safe_array' (for which, read 'safe_list') which goes
through some contortions to avoid accidental nil insertion, so that
there are explicit append() and insert() methods; there should also be
a remove() method. Nice example of the proxy pattern, probably not
very efficient, but I'll work up a benchmark.
http://snippets.luacode.org/snippets/Safe_Array_100
steve d.
Axel Kittenberger
> pages anymore, we need a scratchpad.
>
> Any suggestions?
How about http://piratepad.net/ ?
WIll look through the code.
Axel Kittenberger
anything look if its backportable to 5.1
Axel Kittenberger
* I'd want to have the functions insert, remove etc to be in the
metatable of each list object instead a field in each object. Also to
save memory
* IMHO It would be preferable if the creation function would accept a
table or and argument list. Like list{1,2,3,4} or list(1,2,3,4).
Especially for "arrays" this can be used to put nils in there. The
downside of this is the ambiguity when having only one entry that is a
table, is it an 1-itemed list/array with a table, or is it the table
that shall become a list? I'd default to the second.
* I'd shoot for a C implementation. Since this basic operations should
be as fast as possible, and in the lua culture, the lua distribution
does not come itself with any lua code. So a ""lvanity.c"" or ->
lvanity.so would be preferable.
Kind regards,
Axel
Dirk Laurie
> Its a good start, three things:
>
> * I'd want to have the functions insert, remove etc to be in the
> metatable of each list object instead a field in each object. Also to
> save memory
> * IMHO It would be preferable if the creation function would accept a
> table or and argument list. Like list{1,2,3,4} or list(1,2,3,4).
> Especially for "arrays" this can be used to put nils in there. The
> downside of this is the ambiguity when having only one entry that is a
> table, is it an 1-itemed list/array with a table, or is it the table
> that shall become a list? I'd default to the second.
I should add "write some documentation" to the to-do list :-)
The structure of the code is as follows:
* There is a table called 'list' which does double duty:
1. provides a namespace for the functions insert, remove etc.
So you need to call them as list.insert etc. instead of
table.insert etc.
2. via its call function, creates tables of table type "list".
These tables are proxies for the actual tables, which are stored
in t[index]. The trick comes from PiL. There is also t[param],
which contains local info for each list (only list length actually).
The keys index and param can't duplicate keys that naturally occur
in the actual tables since they are local to the module.
'list' is a constructor, not a prototype of a list object, so insert
etc are not fields in the list objects. I don't think we can work
via prototyping since it is essential to override the __newindex
and __len metamethods.
The constructor takes a table argument list: list{1,2,3,4} is perfectly
acceptable. In fact two such examples are included in vanity_test(),
one to show that nils inside the list are not acceptable (they will
be acceptable for the table type 'array' which I have not got to yet).
This is an important distinction: lists have variable length but no
holes, arrays have fixed length but can have holes.
list(1,2,3,4) is not acceptable at this stage. You're welcome to
modify the code though :-)
I tried the effect of putting the names insert etc in list_mt but
that does not enable t:insert etc. I don't know how to achieve that.
> * I'd shoot for a C implementation. Since this basic operations should
> be as fast as possible, and in the lua culture, the lua distribution
> does not come itself with any lua code. So a ""lvanity.c"" or ->
> lvanity.so would be preferable.
>
Sure, eventually. But it takes weeks to write debugged C code if
you have a working Lua prototype, months if you don't. So the Lua
prototype serves two useful purposes: eventually the development of
the C code will be easier, and in the meantime it's easy to try out
various versions of the semantics.
Dirk
Henning Diedrich
On Jan 13, 6:51 pm, Frank Siebenlist <frank.siebenl...@gmail.com>
wrote:
>
> I'm using Ansca's Corona which has a crippled Lua 5.1 baked-in.
Best,
Henning
Frank Siebenlist
-FS.