Following up on Erik's and keeping track of Alessio's.

Yes. There isn't a CDR specifying "how" to use packages. I have one in mind, but it is bound to be CONTROVERSIAL. So I have not written it upon CDR form. Plus that depends on "fixing the reader errors" (another CDR).

The note regarding packages in the proposed CDR just wants to be cautionary. I think the proposed CDR is not the place where to hash out this problem.

All the best

Marco

On Jun 10, 2013, at 23:52 , Alessio Stalla <alessiostalla@gmail.commailto:alessiostalla@gmail.com> wrote:

Well, it really depends on the CDR; some of them may define a precise API in a specific package and/or don't allow multiple implementations to coexist (e.g. the MOP). Perhaps it would be better to remove any reference to the package system altogether and simply state that some CDRs might be provided by multiple coexisting implementations, and, in those cases, it is not specified how to select one of them.

On Mon, Jun 10, 2013 at 10:38 PM, Erik Huelsmann <ehuels@gmail.commailto:ehuels@gmail.com> wrote: Hi Marco,

Reading the CDR, I wonder: in paragraph 2.1.2 the authors refer to the packaging system as a means to allow co-existing multiple implementations of a CDR in one image. However, the CDR doesn't specify or even advise CDR writers to use packages nor in what way. It seems to me this CDR allows one to detect that a CDR is available in the current image, but it doesn't say *where* the programmer can find it. It feels a bit partial. Is that intended?

Regards,

Erik.

On Mon, Jun 10, 2013 at 2:27 PM, Antoniotti Marco antoniotti.marco@disco.unimib.it wrote: Dear all,

following up the CDR discussion that took place aside the European Lisp Symposium in Madrid a week ago, I prepared this document that specifies how a CL environment can test for the "presence" of a given CDR.

I wanted to pass it around before submitting it formally to the CDR editors.

all the best

Marco

-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.

-- Some gratuitous spam:

http://ripple.com Ripple, social credit system http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM http://code.google.com/p/tapulli my Lisp open source projects http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework

-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.

On Jun 11, 2013, at 24:47 , Pascal J. Bourguignon pjb@informatimago.com wrote:

Antoniotti Marco antoniotti.marco@disco.unimib.it writes:

...

Dear all,

following up the CDR discussion that took place aside the European Lisp Symposium in Madrid a week ago, I prepared this document that specifies how a CL environment can test for the "presence" of a given CDR.

I wanted to pass it around before submitting it formally to the CDR editors.

Specify what format 'n' has: the number of the CDR, represented in base ten without leading 0s.

Good point.

2.1.2)

If multiple implementations of a given CDR are expected, perhaps we should have keywords such as: :LISP=CL :BASE-CHAR=CHARACTER or :WORD-SIZE=64 on *features*, so we could have:

  CDR-{n}={implementation-identifier}

#+CDR-{n}=com.informatimago.common-lisp.cdr-{n} (com.informatimago.common-lisp.cdr-{n}:stuff)

#+CDR-{n}=alexandria (alexandria:stuff)

#-CDR-{n} (do-my-own-stuff)

So specify 2) that implementations of CDRs should do two things:

(pushnew :cdr-{n} *features*) (push :cdr-{n}={implementation-identifier} *features*)

This is interesting, but I am afraid it introduces a source of extra variability. I am assuming that a CDR should represent a "state of affairs" that is already agreed upon. In any case, I think this can go in a subsequent CDR.

2.1.3)

The absence of :cdr-{i} doesn't let infer anything about the present or absent of CDRs from *features*. The presence of :cdr-{n} should imply the presence of :cdr-{i}. What the presence of :cdr-{i} tells us, is the meaning of the absence of :cdr-{n}: it means the CDR is not implemented.

So:

#+(AND CDR-{i} CDR-{n})   should be equivalent in meaning to
#+CDR-{n}   and means CDR-{n} is present (definitely).

#+(AND CDR-{i} (not CDR-{n})) means CDR-{n} is absent (definitely).

#-(and CDR-{i} CDR-{n}) is equivalent to      
#+(or (not CDR-{i}) (not CDR-{n})) which is not helpful:

      - CDR-{n} could implemented, but just :cdr-{n} not on
        *features*, which is possible since CDR-{i} is not
        implemented.

      - CDR-{n} could be not implemented, and therefore  :cdr-{n}
        is rightly not on *features*.


#-(and CDR-{i} (not CDR-{n})) is equivalent to      
#+(or (not CDR-{i}) CDR-{n}) which may mean that:
either
   cdr-{i} is absent and cdr-{n} is absent (see above)
or cdr-{i} is absent and cdr-{n} is present, in case cdr-{n} is
   implemented, but not cdr-{i},
or cdr-{i} is present and cdr-{n} is present (see first case).
But the condition doesn't let us distinguish.

In conclusion, the only interesting expressions are:

#+cdr-{i} (is-implemented CDR-{i}) #-cdr-{i} (is-not-implemented CDR-{i})

#+cdr-{n} (is-implemented CDR-{n}) #+(and cdr-{i} (not cdr-{n})) (is-not-implemented CDR-{n}) #+(and (not cdr-{i}) (not cdr-{n})) (we-don-t-know-anything)

I take you are referring to the :CDR-i where 'i' is the one that may be assigned to the proposal. Yes. All you say is fine.

Cheers

-- Marco Antoniotti