Re: [Lua-users-stdlib] Upheaval (blame Jamie Webb!)

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

On Thursday 05 February 2004 03:22, Johann Hibschman wrote:
> Hm.  From an aesthetic point of view, I'd still rather have functions
> such as map, filter, and their friends in a "list" package, rather than
> in a "vector" package.  "list" is a human word, more accurate than
> "vector" for what amounts to a linear sequence.

In what sense do you mean more accurate?

> I know many people look at "list" and think "linked list", but "vector"
> is just bad.  Well, at least it seems like poor terminology unless you
> can point me at the scaling operators and the identity, and demonstrate
> that they're closed under addition.

Scaling: map(bind(op["*"], x), v)
(identity being x == 1)

Addition: map(op["+"], v1, v2)
Or with Reuben's version: zipWith(op["+"], {v1, v2})
Additive identity: generate(id, 0, table.getn(v))
(closed as usual, and a vector space if you configure Lua to do its arithmetic 
with integers IIRC)

> I suppose that's just taste.  However, to steal an idea from Common
> Lisp, would it be a good idea to have a set of "sequence" functions, in
> their own package, that are designed to be smart enough to try to
> decide what kind of type they're dealing with and Do The Right Thing?

Ideally. The modern take on that is either OOP or generic programming, where 
table, vector, etc. all implement/model sequence. I'd like to see that sort 
of thing, but it doesn't appear to be practical in Lua presently, because 
both require a stronger notion of type. Trying to do it just by analysing 
tables seems very unpleasant.

> I'm still working on my package of lispy routines.  Obvious things that
> I use all the time are "find", "find_if", "position", "position_if",
> and "member."  The other functions, like "substitute", are also handy,
> just not as often.  These can be applied over tables and strings at
> least, and perhaps over other types that are defined.

Well, I hope you'll contribute them when you're done.

> I'm just afraid that if the library becomes too functional, the Typical
> Programmer would have a hard time figuring out how to apply all the
> elegant tools.

As Reuben says, the library has functional stuff for those who want it, and 
more general stuff as well. Functional programming is always going to require 
imperative programmers to adjust their mindset somewhat, and I don't think 
that providing fewer primitives (making it less helpful), or trying to give 
the functions more cuddly names (so they don't match up with the literature) 
is going to change that.