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

[Johann H. <jhi...@ya...>]

On Feb 5, 2004, at 6:48 AM, Jamie Webb wrote:

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

Well, "list" is a natural language word, so it's broad and doesn't 
promise much.  A "vector" is a rather specialized technical word, more 
specialized than even "array", so it promises a lot.

It seems equally likely that someone will see "vector" and think 
"element of a vector space" as someone will see "list" and think 
"linked list".  I think a vanishingly small number of people are going 
to be confused by using the word "list" for something with O(1) access, 
just like a vanishingly small number of people will expect a vector to 
have a fixed dimension and pre-defined mathematical operations.

If that's the case, why not go for the word that's common, has two 
fewer characters, and is easier to touch-type?

> 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 think you missed my point; these definitions work for linked lists 
just as well as for 1D arrays, so they don't really show the 
"vector"-ness of vectors.

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

Hm.  In lisp, they're typically multiple-dispatch "multimethods", so, 
yes, this is OOP, just not in foo.bar(baz) form.  In Lua, I guess all 
you could do would be to have the same functions work for both strings 
and tables, so it's probably not worth the effort.

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

Well, there are cuddly names and there are cuddly names.  "reduce" is a 
better word than "foldl", for one, but "foldl" allows you to also 
define "foldr", which is good.  I think I'd personally rather have 
"reduce" with an optional from_end argument than foldl/foldr, but 
clearly tastes differ.

At work, I'm converting over some old APL programs, so I'll probably 
have some extremely screwy ideas in a few weeks, if I can ever get the 
blasted font to work.  Now _there_'s a concise language.

-Johann