This page is part of the web mail archives of SRFI 14 from before July 7th, 2015. The new archives for SRFI 14 contain all messages, not just those from before July 7th, 2015.
> From goetter@xxxxxxxxxx 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