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