From: Johann H. <jhi...@ya...> - 2004-02-05 03:38:44
|
On Feb 4, 2004, at 5:58 AM, Reuben Thomas wrote: > I'll end with a concrete proposal of what I think is best from the > above: > we should add "vector" and "function" to the current "string", "table" > &c., and put all our additions into those four tables. One or two are > tricky (are map and filter in function or table?) but they all fit in > one > of the four. Once that's done we can take another look. 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. 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. 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? 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. 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. -Johann |