Re: [Lua-users-stdlib] Contribution

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

On Saturday 31 January 2004 20:35, Reuben Thomas wrote:
> And I consider arrays to be fixed length and monomorphic. Also, most of my
> list functions are indeed intended to be used on lists as lists (that
> functional style again). I'm not really sure which is better, but it's
> certainly better to be consistent.

I was thinking more of the complexity of operations. I think of lists as 
having O(n) random access, O(1) head and tail operations, etc. And while it 
seems unlikely that anyone would want anything more array-like than a table, 
I can imagine wanting a linked list, and then wanting the standard operations 
on it.

Everything's an untyped reference in Lua so all tables are monomorphic, but 
maybe 'vector' would be a better name, following Java and C++.

> Of course, with the Set code I give, you can use constructed sets directly
> if you want, and indeed pass ordinary tables to the methods.

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 decided against that approach because you can't rely in it, e.g. it
> > doesn't hold for 'arg', which is otherwise a list/array, and other
> > modules might not use the convention.
>
> ...and given that Lua doesn't have any real type system, maybe that's the
> best thing to do, rather than giving an illusion of it.

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 the latter course would lead to a 'nicer' library, but obviously it 
depends on the Lua authors' take on all this.

> table.concat is evilly named IMO. You either want string.join or
> fold(table, concat_function) when you use it.

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.

> > split_words: I distinguished this from split(), because usually when you
> > split on, e.g. commas, you want to preserve leading and trailing blank
> > fields, whereas usually when you split on whitespace, you don't.
>
> Can't you just use trim in the latter case? If there are two many
> functions half the users will never find the one they need and the others
> will just spend their time learning them all rather than getting work
> done.

Fair enough. I just had it because it's a common case for me.

> > map: My version is extended to allow multiple lists in parallel to be
> > mapped over (i.e. the transpose of your mapWith()).
>
> Or just zipWith, but with the lists as arguments rather than as a list of
> lists.

Ah yes.

> In general I'm against recoding in C, except for a very few primitives.
> It's error prone, and the average programmer can't inspect it.

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.

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

> Now I'm feeling rather daunted, however, mainly over all the
> table/list/set/array operations. I suggest the best way to proceed is to
> try to construct roughly the intersection of what we have between us (in
> terms of the size of the API), but with the union of functionality and,
> where possible, efficiency. How does that sound?

Great, if you think it's achievable.

> Partly I'm worried about alienating programmers without experience of
> functional languages by making the interface as aggressively functional as
> it is at the moment;

1) I've certainly heard it suggested that users with no existing programming 
experience can pick up imperative or functional styles with equal ease.

2) Professional programmers who haven't been exposed to a functional style 
really ought to be. It will help them write better code in any language.

3) I can't see much alternative. If you provide the directly useful 
higher-order functions (map, filter...), you naturally want the complete set 
of them (compose, bind...) because they complement each other. And the 
imperative alternative that first category is just to use control structures; 
no library required.

> Perhaps the terminology might need to be refined: map is a rather
> mathematical word.

OTOH every other language calls it map. It seems to me that new users are 
going to have to learn a name for the function whatever you call it, whereas 
programmers from other languages will be confused/annoyed if it isn't called 
what they expect.

 -- Jamie Webb