[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Namespace management & SRFI-0
> > Remember that an SRFI just describes a property of a Scheme system
> > which is more general than an API consisting of a set of procedures
> > and special forms. [...]
> True -- that issue I didn't know how to deal with.
> But then I'm having trouble seeing how `if-implements' could ever work if
> SRFIs ever conflict (as they will, especially when libraries are revised).
> It becomes an inherently a global operator, with no control over scope or
If two SRFI's conflict then it simply means that if-implements can't
say yes on both (i.e. both can't be implemented at the same time,
which is emminently reasonable since they conflict). There is no
contradiction here. Note however that a given Scheme system might
have two possible "modes" (for example selected with a command line
option) which implements different SRFI's in each mode. In a sense
this Scheme system should be viewed as two Scheme systems which happen
to share most of their executable.
> It sounds, then, like a system which supports conflicting SRFIs could not
> support SRFI-0, which makes me uncomfortable -- I was hoping SRFI-0 could
> specify anchor from which all else could be determined.
It seems like you want a mechanism to **request** a specific feature
within some scope... this sounds very much like a module system.
SRFI-0 is not a module system, it is strictly a mechanism to **test**
that a specific property holds of the host Scheme system. But you
could use SRFI-0 to test if a particular module system is available.
> On the other
> hand, maybe some future SRFI could just contain a conflicting
> specification for `if-implements' in some clever mostly
> backward-compatible way, and SRFI-0 will become deprecated.
This is possible, but I REALLY REALLY hope this will not happen.
SRFI-0 (and the if-implements form) has to be as solid as a rock
because it is the basis on which the whole SRFI business rests. That
is why it has to be simple and clear, and must find widespread
acceptance. I hope noone ever has a reason to propose a new SRFI, say
SRFI-10, with a conflicting semantics for if-implements (for example,
reversing the direction of the two branches of the if-implements),
because a program containing
(if-implements SRFI-1 *X* *Y*)
will be meaningless (since it is not explicit whether this refers to
the semantics of if-implements described in SRFI-0 or SRFI-10). If
you ever feel the urge, at least consider a different name for the new
form (and perhaps the SRFI editors should enforce this).