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

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

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

 To demonstrate the utility of the conditional construct, consider the
 following example:

    (cond-implements
       (srfi-a ... aaa ...)
       (srfi-b ... bbb ...))

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

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

   How about:

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

   ?

I don't see why this makes a difference.  Is the intent that the
implementation not be allowed to choose the ELSE clause if it
doesn't have to?  What if the ELSE clause has a more efficient
implementation than any others?  The existence of a feature
may make the program less efficient rather than more.

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

   No, the way we thought it up, the implementation could indeed make
   different choices from COND-IMPLEMENTS to COND-IMPLEMENTS.  I don't
   see how this is awful.

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

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

Later I do:

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

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