On Jun 11, 2013, at 24:47 , Pascal J. Bourguignon <pjb(a)informatimago.com> wrote:
> Antoniotti Marco
> <antoniotti.marco(a)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.
>
> 1)
>
> 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
