[cdr-discuss] Three RFCs

Marco Antoniotti marcoxa at cs.nyu.edu
Tue Mar 18 19:04:28 UTC 2008


On Mar 18, 2008, at 15:24 , Pierre R. Mai wrote:

>
> Am 18.03.2008 um 15:08 schrieb Edi Weitz:
>
>> On Tue, 18 Mar 2008 14:49:19 +0100 (CET), "Leslie P. Polzer"  
>> <leslie.polzer at gmx.net> wrote:
>>
>>> I'm all for extending CL:CASE in a backwards-compatible way. Why
>>> would that be a problem for CL implementors?
>>
>> It wouldn't be ANSI-compliant anymore.
>
> Also, changes in implementations have been known to contain bugs,  
> hence by forcing the changes to be to cl:case, we are going to  
> potentially affect existing code bases, for no discernible gain.   
> Given the sizable code bases out there, the only circumstances  
> where I find it acceptable to mess with the COMMON-LISP package (or  
> other packages or behaviours mandated by ANSI) is when there is no  
> reasonable way of achieving the intended goal without doing so.  In  
> this case I can see no downsides to placing the extended case (or  
> select, or what have you) symbol in a different package.  Indeed  
> this will aid adoption, since it makes it easier to provide this  
> CDR as a user-maintained library for starters, with implementations  
> still having the ability to optimize the implementation if enough  
> users see the benefit of this (and personally I'd think that most  
> useful optimizations can actually be achieved through user code as  
> well).
>
> Which brings me to another question I've been meaning to bring up  
> w.r.t. the latest CDRs:  Would it be sensible to have a defined  
> package for these kinds of smallish extensions (like e.g. the index  
> types, as well), maybe cdr-cl or ext-cl, or whatever?  Has this  
> been discussed already?

You are opening a can of worms :)  But yes.  At a minimum (and I  
would advocate a non-minimum solution which I will not discuss here)  
every CDR should come in its own package.

Cheers
--
Marco




More information about the cdr-discuss mailing list