a separate configuration language Richard Kelsey (23 Feb 1999 01:31 UTC)
Re: a separate configuration language sperber@xxxxxx (26 Feb 1999 14:17 UTC)
Re: a separate configuration language Richard Kelsey (26 Feb 1999 16:37 UTC)
Re: a separate configuration language sperber@xxxxxx (26 Feb 1999 16:52 UTC)
Re: a separate configuration language Richard Kelsey (26 Feb 1999 20:00 UTC)
Re: a separate configuration language sperber@xxxxxx (28 Feb 1999 09:18 UTC)
Re: a separate configuration language sperber@xxxxxx (01 Mar 1999 15:47 UTC)
Re: a separate configuration language Lars Thomas Hansen (01 Mar 1999 16:03 UTC)

Re: a separate configuration language Richard Kelsey 26 Feb 1999 16:36 UTC

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

   Richard>  - It may be difficult to implement either version of SRFI 0 in the
   Richard>    presence of a module system.  This is certainly the case with
   Richard>    Scheme 48.

   Actually, I have an implementation of our suggestion for Scheme 48 :-)

I would be interested in seeing it.

   There's one change you suggest which we're not happy with:

   Richard> Unlike the proposed COND-IMPLEMENTS, the implementation has no
   Richard> leeway in choosing which clause to use (down with ambiguity!).

   We bounced this around quite a number of times among the editors.  I
   don't know how to better support our case for leaving in the ambiguity
   than what's already in the suggestion:

   > The COND-IMPLEMENTS construct specified here gives Scheme
   > implementations more flexibility in implementing it.  The
   > specification is intentionally ambiguous as to which clause will be
   > expanded in a COND-IMPLEMENTS form.  This is in order to allow Scheme
   > implementations to choose an especially convenient (fastest/least
   > memory-intensive/...) combination of implementations.

How does the implementation know what the programmer has in
mind?  Suppose there are two SRFI's that provide image manipulation,
SRFI-X which can handle both gif and jpeg images, and SRFI-Y that
can only do gif.  The programmer writes

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

Most likely the implementation of SRFI-Y will be smaller and
faster, as it only has to handle one kind of image.  But do you
you really want the implementation to choose the second clause?
Suppose the form were

 (cond-implements (srfi-x 'good)
                  (srfi-y (error "sorry, incompatible implementation")))

No matter how fast SRFI-Y was, I think I would prefer SRFI-X.

Secondly, how much leeway does the implementation have?
If a program contains the following:

 (cond-implements ((and srfi-x srfi-y)
                   ...)
                  (srfi-z
                   ...))

 (cond-implements (srfi-x
                   ...)
                  (srfi-z
                   ...))

can the implementation choose the first clause in the first
form, because it prefers srfi-y to srfi-z, and the second clause
in the second form, because it prefers srfi-z to srfi-x?  This
would be awful.  Both clauses in the first form would have to be
compatible with both clauses in the second form.

It makes sense to allow users to choose between available
SRFIs, as the user may have additional knowledge or requirements,
but the implementation should not override the programmer's
priorities on its own.
                                    -Richard