[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Purpose of SRFI 39
I'd like to ask a question about the fundamental purpose of SRFI 39.
Is it there primarily to a) codify existing practice (which seems
reasonable given that many Scheme implementations already have a
parameter-like API) or b) to present a decent API for putting stuff into
the dynamic environment?
Of course, it could be both, but I'd like to argue that it's far from
a good API for what it's trying to do. My two main objections are:
- The representation for parameters isn't abstract. Of course, we
don't know that we'll want to do things not easily doable with the
procedural representation in the future, but it's possible.
(Similar to the case Marc argued for CALL/CC.)
- The procedure representing a parameter does two completely different
things depending on its number of arguments. It may be just me, but
I don't think that's a particularly good design.
I'd also like to point out that automatic parameter inheritance is not
necessarily a natural choice. In particular, it duplicates
functionality already available via lexical scoping. (I've seen
arguments on this list saying that this is a good thing. I disagree.)
Moreover, it harbors the potential for space leaks because you create
implicit references to objects by spawning threads.
Of course, this is a plug for our paper
Martin Gasbichler, Michael Sperber: Processes vs. User-Level Threads
in Scsh, In The 2002 Scheme Workshop, Pittsburgh, Pa., October 2002.
which discusses design choices for parameter-like facilities.
That leaves (if you agree with me) purpose a) for SRFI 39.
I'm not sure how many systems implement parameters and threads.
MzScheme does and (as has been pointed out) doesn't do sharing for
mutable parameter storage. I think that's a good argument for having
SRFI 39 agree with MzScheme's way of doing things, or eliding mutable
parameters (as has been suggested) entirely.
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla