Denis Washington wrote: > **Take the sequence operations as an example. Each of them only works on a > specific type of sequence - there are separate procedures to retrieve > the length of a list, a vector, a bytevector or a string, for instance. > As a consequence, it is impossible to write procedures that operate on > arbitrary sequences without excessive special-casing. For instance, > writing a generic version of "map" or "filter" would require an ugly > "cond" expression handling each type of sequence individually. And even > then, there would still be the problem that there would be no way to > create user-defined types that act "as if" they were sequences (like > e.g. lazy sequences or streams). I also think it's a little silly to have to implement 'map' separately for strings, vectors, bytevectors, etc. Here's one approach to solving this problem:
https://github.com/dharmatech/indexable-sequence Note that in the above system, some of the operations which are traditionally procedures (e.g. fold-left) are defined as macros. However, they don't have to be macros; this was just an optimisation and an experimental choice. As far as polymorphic code goes, here's an approach to that: https://gist.github.com/585469 And some fancier syntax for the above: https://gist.github.com/631397 Ed _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
