Detecting implementations of CDR specifications...

[Antoniotti Marco]

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.

[Erik Huelsmann]

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 <

Post by Antoniotti Marco
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.

[Alessio Stalla]

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.

Post by Erik Huelsmann
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 <

Post by Antoniotti Marco
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.

[Antoniotti Marco]

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-***@public.gmane.org<mailto:alessiostalla-***@public.gmane.org>> 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-***@public.gmane.org<mailto:ehuels-***@public.gmane.org>> 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 <***@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.

[Pascal J. Bourguignon]

Antoniotti Marco

Post by Antoniotti Marco
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.

1)

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

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*)



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)

[Marco Antoniotti]

Post by Erik Huelsmann
Antoniotti Marco

Post by Antoniotti Marco
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.

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

Good point.

Post by Erik Huelsmann
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
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)
(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.

Post by Erik Huelsmann
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.
#+(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
- 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
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.
#+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