RE: Char sets, Unicode & deadline

[Ben Goetter <goetter@xxxxxxxxxx>]

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:lucier@xxxxxxxxxxxxxxx]
Sent: Wednesday, December 20, 2000 10:47 AM
To: lucier@xxxxxxxxxxxxxxx; shivers@xxxxxxxxxxxxx; goetter@xxxxxxxxxx
Cc: sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx; william.clinger@xxxxxxxxxxxx;
feeley@xxxxxxxxxxxxxxxx; srfi-14@xxxxxxxxxxxxxxxxx
Subject: RE: Char sets, Unicode & deadline


> From goetter@xxxxxxxxxx  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:lucier@xxxxxxxxxxxxxxx]
> > From goetter@xxxxxxxxxx  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