Re: [Lua-users-stdlib] Contribution

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

> I can imagine wanting a linked list, and then wanting the standard operations
> on it.

But tables give you those operations and with lower complexity. What's the
problem?

> Everything's an untyped reference in Lua so all tables are monomorphic,

Strings? Numbers? Threads? Functions? Booleans?

> but maybe 'vector' would be a better name, following Java and C++.

Sounds good, as in "vector" = "resizable array". I'm certainly beginning
to agree that in Lua it's better to use your style of definitions rather
than explicit types ("table", "vector", "set").

> Not so nice to use ordinary tables: Set.add({ set = s }, e)
> That sort of not-really-encapsulation doesn't exactly set a shining example.

I'd forgotten I had the set in a set member, and came up against that last
night with some old code. This will be fixed.

> I think there are two options: go the current Lua way and don't encourage OO
> usage because it might not work, or in the longer term work with the Lua team
> to allow tables to be more effectively typed though a combination of
> convention and language support, so that OOP at this level becomes more
> feasible.

I think you can do both. Being more Lua-ish for basic types (like your
library) doesn't preclude being OO-ish for objects (which can contain and
be contained in the Lua-ish types quite happily). I've certainly written
code like this (even my library doesn't formalise lists, after all).

> I think the latter course would lead to a 'nicer' library,

Depends what for. I want to leave the core tables stuff in the library as
simple as possible so that everyone can use it in even their most basic
scripts. That's certainly the only way the Lua authors are likely to get
interested. The special-purpose stuff like getopt and parsers can quite
happily be more OO: it's the sort of thing that attracts users because it
already does most of their job, but only if they're doing that specific
thing.

> but obviously it depends on the Lua authors' take on all this.

My take so far is that they have no interest in it. I think the best shot
to get some really useful stuff in the standard distribution is with the
core functions like map, filter, join &c., introducing no new types.
Probably just want to put them all in table.

> Makes sense. It does seem a reasonable goal of the standard library to
> completely supplant the Lua libraries where their interfaces seem suboptimal,
> and then lobby for its inclusion (or inclusion of a subset) into Lua 6.
> Having this library in Lua would certainly improve its position w.r.t.
> setting conventions for these simple structures.

I agree completely.

> > Can't you just use trim in the latter case? If there are two many

Aargh. "two many"? I cringe with shame.

> In general, I agree. It seems like map() is pretty primitive though, and
> especially if this library were to replace the current Lua libraries it would
> need some amount of C code.

I would really like to see proof that map being coded in C makes a
difference: the amount of Lua code in it is tiny, and surely the vast
majority of the time will be spent in the table construction even if it's
not spent in the function.

Peversely, it does seem almost more likely that the Lua team will look
kindly on new C code than new Lua code...which is silly, because the
maintenance cost of Lua code from version to version is so much lower.

> > > shallow_copy: You've called it clone(). I used the more explicit name to
> > > distinguish it clearly from deep_copy().
> >
> > It's a pity, because I prefer the shorter name.
>
> There are probably shorter names for the two that would be sufficient to
> distinguish them. mimic() and duplicate() come to mind, but maybe some
> quality time spent with a thesaurus would yield something better.

How about "copy" (for shallow) and "clone" (for deep)?

Everything else: right on.

-- 
http://www.mupsych.org/~rrt/ | aphorism, n.  a wise lie