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 sperber@xxxxxx 26 Feb 1999 16:52 UTC

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

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

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

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

Richard> Suppose the form were

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

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

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

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

?

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

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

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

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

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.

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

If the programmer has priorities that she wants to override the
implementation guesses, she can just write cascaded COND-IMPLEMENTS
forms as suggested above.  (Maybe a derived IF-IMPLEMENTS would be
helpful in that case.)

--
Cheers =8-} Mike