[cdr-discuss] [CDR 2] What's the package?
Hi, [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.) 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. 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? Any ideas? Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
Pascal Costanza <pc@p-cos.net> writes:
The specification of generic hash tables misses a specification of the package in which the functionality is to be found.
Not in the version I'm looking at: section 1.2.1 (on the first page) is clear that the name is GENHASH, no?
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.
Please, no. If there is demand from users to aggregate implementations of CDRs into one package, then they can either define themselves or lobby their vendors to aggregate symbols from disparate packages into a single package.
Any ideas?
I don't see why a proliferation of package names is inconvenient; even if it is, I don't see an already-accepted solution in the community out there. (If you know of one, maybe you should write it up as a CDR... :-) Cheers, Christophe
On 3 Dec 2006, at 14:30, Christophe Rhodes wrote:
Pascal Costanza <pc@p-cos.net> writes:
The specification of generic hash tables misses a specification of the package in which the functionality is to be found.
Not in the version I'm looking at: section 1.2.1 (on the first page) is clear that the name is GENHASH, no?
Oops. Indeed, it couldn't be more clear than that...
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.
Please, no. If there is demand from users to aggregate implementations of CDRs into one package, then they can either define themselves or lobby their vendors to aggregate symbols from disparate packages into a single package.
Any ideas?
I don't see why a proliferation of package names is inconvenient; even if it is, I don't see an already-accepted solution in the community out there. (If you know of one, maybe you should write it up as a CDR... :-)
OK. ;) (Which means: No, I don't know of one...) Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
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).
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. //Ingvar
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@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
participants (3)
-
Christophe Rhodes -
Ingvar -
Pascal Costanza