> From xxxxxx@mazama.net  Wed Dec 20 14:01:25 2000
>
> Forgive me for being dense, but how can you be able to implement cs-filter
> efficiently and not pred->cs?  You're going to have to write pred->cs as
> half of cs-filter, before the union op.

If one has a sparse representation for characters with (char->integer
ch) > 255 in a char-set, or a sparse block representation, then it's
not bad at all to implement cs-filter.

> Problem is that the proposed rev evangelizes char-set-filter +
> char-set:ascii as the portable safe-performance solution.

I don't see this.  Olin's email only mentions ASCII once in

> A follow-on SRFI will need to define ways to generate useful "universe"
> char sets; this SRFI only provides a very-portable CHAR-SET:ASCII &
> CHAR-SET:FULL (whatever that may happen to be).

(I hope Olin forgives me for posting private e-mail.)  It's not clear
to me that he even intended to put this sentence in the spec; I'd
hardly call this "evangelizing" ASCII.

> Again, I want laziness only as an option.

Yes, but if you don't want to implement this option, and I don't, it
takes an hour for pred->cs to return on my Alpha.  I see this as a big
problem.

Brad