Re: [Lua-users-stdlib] Contribution

[Jamie W. <j...@jm...>]

On Wednesday 04 February 2004 09:44, Reuben Thomas wrote:
> I meant Lua lists. Are you thinking of implementing a linked list type in
> C?

Not especially, e.g.:

list = { h = "Item 1", t = { h = "Item 2", t = { h = "Item 3", t = nil }}}

Insertion at a random point in such a structure is O(1) if you've already 
found that point, whereas it's O(n) for vectors. Trees also have their 
advantages at times (e.g. when keys are complex, since 'equal' Lua tables 
don't hash the same, or simply as a compromise between lookup and ordered 
insert speed). Just because we have this built-in hash-table doesn't mean 
that other classic data structures don't have their uses, and standard 
libraries for other langauges tend to implement them.

> Maybe this is something to sort out. If we get a coherent and compelling
> story, and implement it without dependencies on the rest of stdlib, it
> could get into the base distribution. The Lua authors themselves admitted
> (before 5.0) that the libraries hadn't had as much attention as they
> deserved, so the case for fine-tuning (which this essentially is) is still
> strong. LuaPlus addresses similar issues (e.g. metatables for all types).

Certainly worth a try.

> What about "for all tables"? Setting it for a particular bound variables
> seems a bit screwy. Also, there's a one-line fix to allow you to get at
> the metatable for tables (which already exists).

Well yes, but I don't think you would want all tables being vectors by 
default, so arg would need to be treated separately.

> You mean because of popping arguments off the Lua stack instead of
> stuffing them into a table? Point.

Yes, and also it should be possible to avoid building lists, concatenating 
them, then unpacking them, as in e.g. bind().

> Except that the point shouldn't just be to provide things you can't
> implement in Lua, but to provide things that make programming more
> productive. A lot of what we've done fits into that bracket: the very fact
> that we both line-for-line implemented many of the same functions suggests
> they have merit; plenty of programmers will not even know they exist.

I think the Lua authors argument is that it is much harder to mess about with 
binary modules, so for simple stuff it's best if you don't have to, whereas 
it's very easy to download Lua code separately and dofile() it.

> > > How about "copy" (for shallow) and "clone" (for deep)?
> >
> > Clone certainly sounds like a deep copy to me. Not so sure about copy
> > though. I think that could mean either, as evidenced by the terms deep
> > and shallow copy.
>
> I think I'll go with that for the present. I think that finding a better
> balance between short, obvious names and unambiguous ones will be hard,
> but of course I'm still open to suggestions.

Mmm... I really wish there was a consensus on this:

Java has clone for shallow or deep copy depending on the programmer's mood 
today.
C# has clone for deep copy
Python and Smalltalk have copy and deepcopy
ML typically has copy meaning deep copy
Ruby has dup for shallow copy and clone for something which doesn't appear to 
be either.
ADA uses 'all' for deep copy

So, I suppose copy and clone are as good as anything else. Everything's going 
to be confusing to someone.

 -- Jamie Webb

Whatever you're thinking, you're wrong.