Detecting implementations of CDR specifications...

[Marco Antoniotti]

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

> Antoniotti Marco
> <antoniotti.marco at 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