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