> Some procedures analogous to those of Haskell's Prelude are also defined,
> but they are more Schematic: (values)-aware and explicitly tail-recursive
> where possible. For example, (filter proc list1 list2...) acts like
> Haskell's filter, but returns several list values when there are more than
> one list arguments (proc should accept as many arguments and is applied to
> all the lists elementwise); and ($*) is a functional composition combinator,
> defined as this:
> ($*)                                    ===> values
> ($* proc)                            ===> proc
> ($* proc1 proc2 proc3 ... proc_n)  ===> the composition of proc1, ..., by
> the following rules:
[...]

I think that there's a nice tradition among the Scheme programmers to
use the name "compose" to refer to a composition function. It is much
more descriptive than "dollar-asterisk" ("multiply dollars"? "a
millionare marries a star"? "jackpot"?), and hence more
reader-friendly, and unless you are doing some domain-specific
research, your programs usually won't get much longer because of that.

As to the behaviour of "filter", it is not clear whether it should
behave as you described when more than one list is provided. Perhaps
it should rather iterate over their cartesian product? Or concatenate
the lists? That's one more thing to remember, and eventually one more
thing to forget. If you're doing something complex, don't let your
code pretend that it's something simple.

Regards

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports