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)
|
>>>>> "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