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

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

On Friday 06 February 2004 03:42, Johann Hibschman wrote:
> 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.

That's just it though: all three are rather specialised technical words. The 
exact way in which they are specialised depends on the field you work in. 
Since Lua is a mixed imperative/functional language, we should take our 
definitions from those worlds: Arrays are fixed-size, n-dimensional mutable 
structures with O(1) random access, O(n) inserts, etc., Vectors are 
single-dimensional, mutable and resizable in imperative languages, with O(1) 
random access, O(n) inserts, etc. Lists are mutable and resizable in 
imperative languages, and have O(n) random access and O(1) inserts. Data 
Structures books may qualify such lists as linked lists, but programming 
languages such as C++, ML, and LISP don't.

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

Difference: A [Lua table with integer keys] may well be a member of a vector 
space (well, as good as; I don't think double quite qualifies as a field), 
but it would never be a linked list.

Also, the implications of a misunderstanding differ: If a user were to assume 
he was dealing with a mathematical vector when in fact he wasn't, that could 
only be as a consequence of a more direct misunderstanding of the operations 
he is performing, and the interpreter is likely to complain very quickly. 
OTOH, if a programmer were to assume he was dealing with a linked list, he 
could quite happily produce a working program, only to discover once he tries 
it on production-scale data that it runs N times slower than expected.

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

They show that vectors, arrays, and lists all satisfy your 'element of a 
vector space' criterion. Therefore, in mathematical terms, we could call any 
one of them a vector (assuming the elements are numbers). In programming 
terms, as explained above, a [Lua table with integer keys] has the properties 
of a vector, and not those of an array or list.

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

Indeed.

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

Well, Reuben already has zip = unzip = transpose. Maybe there's an argument 
for having foldl = reduce, map = foreach, etc.

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

Mmm... I thought those people who still dealt with APL tended to use ASCII 
representations these days?

-- Jamie Webb