[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a separate configuration language
>>>>> "Richard" == Richard Kelsey <kelsey@xxxxxxxxxxxxxxxxxxx> writes:
Richard> References: <199902261636.LAA11953@xxxxxxxxxxxxxxx>
Richard> From: sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx (Michael Sperber [Mr. Preprocessor])
Richard> Date: 26 Feb 1999 17:52:16 +0100
Richard> Sure, that's just not the way we intended it to be written.
Richard> It's the way you wrote it in the revised SRFI. I quote:
Richard> where the programmer is implementing some abstraction that can use
Richard> function aaa from SRFI a or can use function bbb from SRFI b. However,
Richard> the semantic fit with aaa is substantially better, which the programmer
Richard> recognized by giving that implementation first.
Ooops. Our wording is obviously incorrect. It's probably a remnant
from an earlier draft. This should be fixed. I'll get to work on
Richard> All I did was make srfi-a and srfi-b a little more concrete.
Richard> How about:
Richard> (srfi-x 'good)
Richard> (srfi-y (display "GIF only, sorry")
Richard> ... jpeg stubs that raise errors ...))
Richard> I don't see why this makes a difference. Is the intent that the
Richard> implementation not be allowed to choose the ELSE clause if it
Richard> doesn't have to?
Exactly. This should also be clarified. Sorry for the sloppy
Richard> What if the ELSE clause has a more efficient implementation
Richard> than any others? The existence of a feature may make the
Richard> program less efficient rather than more.
Then you should have written your COND-IMPLEMENTS form the other way
around, using NOT. (Now I finally see what NOT is for. You read
Richard> What bothers me is that the programmer and user know so much and
Richard> the implementation knows so little. All the implementation knows
Richard> about is the general efficiency of its SRFI implementations.
Richard> It knows nothing about the semantic loss of a particular choice,
Richard> or the actual efficieny gains. What if the semantic loss is
Richard> crucial to the user, or if the program only makes minimal use
Richard> of an SRFI? In neither case would the efficieny matter.
I agree, but as pointed out above, the idea of COND-IMPLEMENTS is that
the implementation must choose a non-ELSE branch if it can. This
allows you to write down a linear conditional if you want.
Richard> It makes it hard to determine what program is actually going to run.
Richard> Suppose SRFI-Y defines function Y and SRFI-Z defines function Z and
Richard> both require some kind of initialization. My program leads off with:
Richard> (cond-implements ((and srfi-x srfi-y)
Richard> ... initialize y using x ...)
Richard> ((and srfi-x srfi-z)
Richard> ... initialize z using x ...)
Richard> (error "insufficient implementation")))
Richard> Later I do:
Richard> (cond-implements (srfi-y (y))
Richard> (srfi-z (z)))
Richard> If the implementation prefers SRFI-Z to SRFI-Y in the presence
Richard> of SRFI-X, but the other way around without SRFI-X, then this will
Richard> break because the second form will call the uninitialized SRFI.
Richard> In fact, there is no COND-IMPLEMENTS form I can write which will
Richard> necessarily call the correct function, if the implementation is
Richard> free to ignore previous choices.
Sure, but that's because your program is buggy.
(cond-implements ((and srfi-x srfi-y)
... initialize y using x ...)
(define a y)
((and srfi-x srfi-z)
... initialize z using x ...)
(define a z)
(error "insufficient implementation")))
I agree this needs to be documented more clearly.
Cheers =8-} Mike