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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports