[cdr-discuss] CDR follow ups...
Hi, At ELS'12 in Zadar there was a brief discussion about how we could make the CDR process more active. One observation was that there is not enough follow up on CDRs. Especially two things were mentioned: (a) It is not easy to figure out which CL implementations implement which CDRs. (b) It is not easy to figure out which CDR is implemented in a running CL system. About (a): I don't think the CDR website should maintain a list of implemented CDRs. This would increase the maintenance overhead of CDR, and would be detrimental to the goal of CDR being a strictly light-weight process. However, what could be done is to add a page to CLiki, for example, where volunteers could add the necessary information. What do you guys think? Is CLiki a good place for this? There is a chance that this could get out of sync with what implementations actually do, but this should still be easier to maintain than putting such information on the CDR website… About (b): A suggestion was that CDRs could be represented as entries in *features* (so :cdr-1, :cdr-2, :cdr-3, etc.). This would be the most general form of providing something that can be tested, because it can even be tested at compile time. Does that make sense? Should this be written up as a CDR of its own? Pascal -- Pascal Costanza
Pascal Costanza wrote:
(a) It is not easy to figure out which CL implementations implement which CDRs.
(b) It is not easy to figure out which CDR is implemented in a running CL system.
And possibly (c): it is not easy to figure out which CDR should be considered as an update for a previous one, hence rendering the previous one obsolete. This situation may not have happened yet, but still...
About (b): A suggestion was that CDRs could be represented as entries in *features* (so :cdr-1, :cdr-2, :cdr-3, etc.). This would be the most general form of providing something that can be tested, because it can even be tested at compile time. Does that make sense? Should this be written up as a CDR of its own?
I think there was a thread about that here with more ideas, but I need to check on that later (I'm still celebrating the eviction of Nicolas-The-Little-Nervous :-). -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
Hi, I checked the existing threads on this topic (not sure if I was exhaustive). There are two elements being proposed: (a) having something like :cdr-nnn in *features*, and (b) having a standard package naming mechanism. One suggestion actually was to have :cdr-nnn also as a package name. It seems to me that :cdr-nnn for *features* is straightforward and no objections were ever raised, as far as I can tell. :cdr-nnn as package name seems more dubious to me, but that's just my personal opinion. There is indeed no way to figure out which CDR is an update to which other CDR. My opinion is that this should be kept like this. There could be situations where different people have different views on whether a particular CDR is an improvement on a previous one or not, and there shouldn't be a mechanism in place that can be abused in any way for political reasons. Just my 0.02€. ;) Pascal On 6 May 2012, at 21:55, Didier Verna wrote:
Pascal Costanza wrote:
(a) It is not easy to figure out which CL implementations implement which CDRs.
(b) It is not easy to figure out which CDR is implemented in a running CL system.
And possibly (c): it is not easy to figure out which CDR should be considered as an update for a previous one, hence rendering the previous one obsolete. This situation may not have happened yet, but still...
About (b): A suggestion was that CDRs could be represented as entries in *features* (so :cdr-1, :cdr-2, :cdr-3, etc.). This would be the most general form of providing something that can be tested, because it can even be tested at compile time. Does that make sense? Should this be written up as a CDR of its own?
I think there was a thread about that here with more ideas, but I need to check on that later (I'm still celebrating the eviction of Nicolas-The-Little-Nervous :-).
-- Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
_______________________________________________ cdr-discuss mailing list cdr-discuss@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cdr-discuss
-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
Pascal Costanza wrote:
There are two elements being proposed: (a) having something like :cdr-nnn in *features*, and (b) having a standard package naming mechanism. One suggestion actually was to have :cdr-nnn also as a package name.
One more thing to consider is that it may not necessarily be a good thing to have the implemented CDRs active by default. For instance, I would like to be able to (require :cdr-nnn) when I want one, but also be able to live without it if I want to. If that were possible, I think the whole discussion on #; could just go away ;-)
There is indeed no way to figure out which CDR is an update to which other CDR. My opinion is that this should be kept like this. There could be situations where different people have different views on whether a particular CDR is an improvement on a previous one or not, and there shouldn't be a mechanism in place that can be abused in any way for political reasons. Just my 0.02€. ;)
Okay, so s/update to/based on/. Regardless of any judgment of value, I still think it would be useful to have a tree (graph?) view on the available CDRs, their update/fork/merge/dependency/younameit history. Maybe a denotation mechanism is not needed. Every CDR can perfectly state that it considers itself as a followup, update or whatever else to another another one. Every CDR can also perfectly state that some others are required for it to work. But if the whole CDR thing is to grow, I fear that the situation could become messy. The point is just to make that kind of information easier to get; not to force any particular usage of it. In practice, nothing prevents you from writing "this CDR is considered an improvement over CDR #". But nothing prevents you from completely disregarding that statement either :-) -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
Pascal Costanza wrote:
I checked the existing threads on this topic (not sure if I was exhaustive).
There are two elements being proposed: (a) having something like :cdr-nnn in *features*, and (b) having a standard package naming mechanism. One suggestion actually was to have :cdr-nnn also as a package name.
It seems to me that :cdr-nnn for *features* is straightforward and no objections were ever raised, as far as I can tell. :cdr-nnn as package name seems more dubious to me, but that's just my personal opinion.
About the package idea, see also this thread stated by Juanjo on the ECL mailing list: http://www.mail-archive.com/ecls-list@lists.sourceforge.net/msg01225.html There are a couple of very good arguments from Pascal Bourguignon in favor of using packages for CDRs defining new symbols (although I find his criticisms a little exagerated; we don't have to deal with soooo many Lisp implementations after all). But in any case, I think he's right. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com
On May 20, 2012, at 20:58 , Didier Verna wrote:
Pascal Costanza wrote:
I checked the existing threads on this topic (not sure if I was exhaustive).
There are two elements being proposed: (a) having something like :cdr-nnn in *features*, and (b) having a standard package naming mechanism. One suggestion actually was to have :cdr-nnn also as a package name.
It seems to me that :cdr-nnn for *features* is straightforward and no objections were ever raised, as far as I can tell. :cdr-nnn as package name seems more dubious to me, but that's just my personal opinion.
About the package idea, see also this thread stated by Juanjo on the ECL mailing list: http://www.mail-archive.com/ecls-list@lists.sourceforge.net/msg01225.html
There are a couple of very good arguments from Pascal Bourguignon in favor of using packages for CDRs defining new symbols (although I find his criticisms a little exagerated; we don't have to deal with soooo many Lisp implementations after all). But in any case, I think he's right.
I am kind of vary about using packages (or package nicknames) mandated as part of CDR; not because I disagree with PB, but because once you start talking about packages, you need to talk about naming conventions and conflicts. I am all for using the CDR-NNN in *features* of course. I could write a CDR about "package naming", but that would mean that CDR should agree on *a* naming convention - a CDR in itself - and assume that the underlying implementation signals nicknames conflicts - yet another CDR. The bare bone version of such thing is (defpackage "IT.UNIMIB.DISCO.MA.MY-CDR-42-IMPLEMENTATION" (:use …) (:nicknames "THE-CDR-AGREED-UPON-MEANINGFUL-AND-MAYBE-HIERARCHICAL-NAME" "CDR-42" …) (:export …) …) Cheers -- MA
* Pascal Costanza <cp-99BKOWH6pVcrbJU0hmoH5j@choyvp.tznar.bet> [2012-05-19 19:05:00 +0200]:
It seems to me that :cdr-nnn for *features* is straightforward and no objections were ever raised, as far as I can tell.
*features* is already often so long, it is hard to navigate. I know it is a lame objection, and it is quite possible that :cdr-nnn is the way to go, but I am still wary about mandating too many *features* elements. Imagine there are hundreds of CDR's, some might well be very complicated, so that for a cleanup of the pathname system, e.g., we will have something like #+(or cdr-33 cdr-33-12 cdr-33-12-7) to check for a feature specified in the section 12.7 of the CDR 33. :-) -- Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000 http://www.childpsy.net/ http://iris.org.il http://palestinefacts.org http://jihadwatch.org http://thereligionofpeace.com Those, who refuse to do the math, are doomed to talk nonsense.
participants (4)
-
Didier Verna -
Marco Antoniotti -
Pascal Costanza -
Sam Steingold