>>>>> "Richard" == Richard Kelsey <xxxxxx@research.nj.nec.com> writes:

Richard>    References: <199902261636.LAA11953@kima.nj.nec.com>
Richard>    From: xxxxxx@Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor])
Richard>    Date: 26 Feb 1999 17:52:16 +0100

Richard>    Sure, that's just not the way we intended it to be written.

Richard> It's the way you wrote it in the revised SRFI.  I quote:

Richard>  where the programmer is implementing some abstraction that can use
Richard>  function aaa from SRFI a or can use function bbb from SRFI b. However,
Richard>  the semantic fit with aaa is substantially better, which the programmer
Richard>  recognized by giving that implementation first.

Ooops.  Our wording is obviously incorrect.  It's probably a remnant
from an earlier draft.  This should be fixed.  I'll get to work on
something tomorrow.

Richard> All I did was make srfi-a and srfi-b a little more concrete.

Richard>    How about:

Richard>    (cond-implements
Richard>      (srfi-x 'good)
Richard>      (else
Richard>        (cond-implements
Richard> 	(srfi-y (display "GIF only, sorry")
Richard> 		(newline)
Richard> 		... jpeg stubs that raise errors ...))

Richard>    ?

Richard> I don't see why this makes a difference.  Is the intent that the
Richard> implementation not be allowed to choose the ELSE clause if it
Richard> doesn't have to?

Exactly.  This should also be clarified.  Sorry for the sloppy
wording.

Richard> What if the ELSE clause has a more efficient implementation
Richard> than any others?  The existence of a feature may make the
Richard> program less efficient rather than more.

Then you should have written your COND-IMPLEMENTS form the other way
around, using NOT.  (Now I finally see what NOT is for.  You read
this, Dave?)

Richard> What bothers me is that the programmer and user know so much and
Richard> the implementation knows so little.  All the implementation knows
Richard> about is the general efficiency of its SRFI implementations.
Richard> It knows nothing about the semantic loss of a particular choice,
Richard> or the actual efficieny gains.  What if the semantic loss is
Richard> crucial to the user, or if the program only makes minimal use
Richard> of an SRFI?  In neither case would the efficieny matter.

I agree, but as pointed out above, the idea of COND-IMPLEMENTS is that
the implementation must choose a non-ELSE branch if it can.  This
allows you to write down a linear conditional if you want.

Richard> It makes it hard to determine what program is actually going to run.
Richard> Suppose SRFI-Y defines function Y and SRFI-Z defines function Z and
Richard> both require some kind of initialization.  My program leads off with:

Richard>   (cond-implements ((and srfi-x srfi-y)
Richard>                     ... initialize y using x ...)
Richard>                    ((and srfi-x srfi-z)
Richard>                     ... initialize z using x ...)
Richard>                    (else
Richard>                     (error "insufficient implementation")))

Richard> Later I do:

Richard>   (cond-implements (srfi-y (y))
Richard>                    (srfi-z (z)))

Richard> If the implementation prefers SRFI-Z to SRFI-Y in the presence
Richard> of SRFI-X, but the other way around without SRFI-X, then this will
Richard> break because the second form will call the uninitialized SRFI.
Richard> In fact, there is no COND-IMPLEMENTS form I can write which will
Richard> necessarily call the correct function, if the implementation is
Richard> free to ignore previous choices.

Sure, but that's because your program is buggy.

(cond-implements ((and srfi-x srfi-y)
                  ... initialize y using x ...)
                  (define a y)
                 ((and srfi-x srfi-z)
                  ... initialize z using x ...)
                  (define a z)
                 (else
                  (error "insufficient implementation")))

(a)

I agree this needs to be documented more clearly.

--
Cheers =8-} Mike