[cdr-discuss] [CDR 2] What's the package?

[Pascal Costanza]

On 3 Dec 2006, at 22:57, Ingvar wrote:

> Pascal writes:
>> [I am posting this as a regular Common Lisper, not as a CDR editor.]
>>
>> The specification of generic hash tables misses a specification of
>> the package in which the functionality is to be found. The reference
>> implementation defines a package net.hexapodia.hashtables with a
>> nickname genhash. This should, IMHO, be part of the specification.
>> Otherwise, we get into the situation as with the CLOS MOP, where each
>> implementation uses its own package name for some semi-standard
>> library. (This is admittedly not a serious issue, but it is
>> inconvenient nonetheless.)
>
> Good point. I believe my intention was taht all functionality would be
> provided from the package designator :GENHASH (that is, as you can  
> see, a
> nickname of the implementation-specific package name). I will make  
> a change to
> CDR 2 right now and aim to have it uploaded by, say, tomorrow (just  
> in case
> something else comes through at the last minute).

It wasn't only your intention, you actually said so very clearly in  
the spec. The mistake is on my side, sorry for the fuzz.

>> On a more general note: Do we need a more general mechanism for
>> assigning package names? One potential problem I see coming up is
>> that each CDR uses its own package name, which could lead to a
>> proliferation of package names which in turn is also quite  
>> inconvenient.
>
> As long as the CDRs cover "sufficiently different" subject areas, I  
> don't see
> a proliferation of package names to be a problem. At least for  
> myself, I try
> to keep to "one functionality group, one package name", with  
> (possibly) a
> library-user's package importing and re-exporting package names.  
> But, then, I
> am in the habit of NOT using USE-PACKAGE to a great extent.
>
>> Do we need a common CDR package for collecting different CDR
>> proposals? This might be impractical as well because we
>> (intentionally) do not have a way to approve CDRs. How would we avoid
>> name clashes across different CDRs?
>
> MMy gut-feel is that an all-encompassing CDR package is the wrong  
> thing,
> though at this moment in time I can't provide a godo argument one  
> way or
> another.

I am not really happy about my suggestion either. It's probably  
indeed better to leave things as they are for the time being.


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium