[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Char sets, Unicode & deadline
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
Again, I want laziness only as an option.
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;
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
> > 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.