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.

Problem is that the proposed rev evangelizes char-set-filter +
char-set:ascii as the portable safe-performance solution.  Naive client
either calls that and gets a char-set limited to the ascii domain, or
supplies char-set:full and hits all the problems thereon that you've already
described.

Again, I want laziness only as an option.

-----Original Message-----
>From: Brad Lucier [mailto:xxxxxx@math.purdue.edu]
Sent: Wednesday, December 20, 2000 10:47 AM
To: xxxxxx@math.purdue.edu; xxxxxx@cc.gatech.edu; xxxxxx@mazama.net
Cc: xxxxxx@informatik.uni-tuebingen.de; xxxxxx@east.sun.com;
xxxxxx@IRO.UMontreal.CA; srfi-14@srfi.schemers.org
Subject: RE: Char sets, Unicode & deadline

> From xxxxxx@mazama.net  Wed Dec 20 13:43:31 2000
>
> I want the option of efficient in storage, as well as speed.  If I can't
> call pred->cs later, I have to deliver it as a precomputed bitmap.  Oink.
>
> -----Original Message-----
> From: Brad Lucier [mailto:xxxxxx@math.purdue.edu]
> > From xxxxxx@mazama.net  Wed Dec 20 13:34:58 2000
> > I urge you to keep your original function, which was elegant: simply
allow
> > it, optionally, to be lazy.
>
> Sounds no good.  I figure I should be able to implement such a thing
> efficiently and I can't see how.
>

If pred->cs is not in theis SRFI, then you can implement it however
you want.  I'm not enthusiastic about having to implement such a
beast just to claim that my implementation is SRFI-14 compliant.

Brad