[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