[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Namespace management & SRFI-0
> I guess that answers my question -- any management of conflicting SRFIs is
> to be outside the SRFI mechanism itself (or at least SRFI-0).
> I appreciate and agree with your goals for a simple `if-implements'.
> However, I am have some remaining concerns. I wouldn't want a user to
> have to try a bunch of different command-line options to get a program to
> Perhaps this is the solution:
> Would a reasonable SRFI, in your view, specify a "program-suggests"
> special form whose effect is to communicate to the Scheme system that the
> program is going to test for some features (SRFIs) and would very much
> like to have them available if possible. The implementation is free to
> ignore the suggestions if it so chooses.
> (program-suggests SRFI-1)
> (if-implements SRFI-1
> (error "you lose -- go get a real Scheme system :-)"))
> ... blah blah blah using SRFI-1 features ..
I'm not fond of this idea. Once again the problem is binding time...
when does the suggestion of the (program-suggests SRFI-1) take effect?
If the compiler can satisfy the suggestion, which branch is
chosen in (if-implements SRFI-1 A B) if
1) the form (if-implements SRFI-1 A B) is after (program-suggests SRFI-1)
2) the form (if-implements SRFI-1 A B) is before (program-suggests SRFI-1)
3) the form (if-implements SRFI-1 A B) is in another module
I don't see any good answers... and because there are so many
variations possible I suggest that such a mechanism be relegated to a
On the other hand I really think that what you want is a module
system. In fact I think that the SRFI process should not be used for
specifying sets of procedures that could easily form a module (for
example SRFI-1). SRFIs should mainly focus on describing basic
functionalities that can't be implemented portably and that have to be
part of the Scheme system itself. Things like: modules, exceptions,
records, IEEE floating point, Unicode, binary I/O, etc.