[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Char sets, Unicode & deadline

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.

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.

-----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
> > 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.