From: Johann H. <jhi...@ya...> - 2004-02-06 03:42:33
|
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 |