Re: [Lua-users-stdlib] Contribution

[Reuben T. <rr...@sc...>]

> > But tables give you those operations and with lower complexity. What's the
> > problem?
>
> Linked lists have faster inserts and deletes,

I meant Lua lists. Are you thinking of implementing a linked list type in
C?

> It needs to be there though if you're going to do OOP, otherwise you might
> have a set containing the name of one of your methods.

I don't want to do OOP on sets any more.

> With the current Lua table stuff, one can set { __index = table } for a vector
> and have nice OO operations like t:getn(), and that's great, except that it's
> unreliable since any vectors a function receives need not have __index set.
> My problem is that it seems clear the the Lua authors intended the OO
> behaviour to be available for vectors, but failed to follow through. That
> makes me unsure as to what exactly the 'Lua way' is supposed to be.

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

> What I'd like to see in the language I think is a) a way to set the default
> metatable for 'arg',

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

> Your map probably wouldn't be much different, but anything variadic can
> probably become noticeably faster in C.

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

> Most of the current Lua library functions are not implementable in Lua,
> or at least not efficiently, and that could be the criteria for any
> further additions.

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.

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

-- 
http://www.mupsych.org/~rrt/ | impatience, n.  the urge to do nothing