[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New SRFI 0 draft
> Many thanks, Marc, for the new draft. It's a definite improvement.
Good... forward progress!
> >From a first look (I'll have a second look tomorrow),
> I'd still like to suggest two things to be addressed:
> - Import of feature implementations (IMHO) *needs* to be made
> explicit. Scheme implementations which load additional features
> on-demand (such Scheme 48) would *have* to say NO to any feature
That is not true. "cond-expand" has to be built-in. So implementors
have to add some built-in support in their implementation to use
SRFIs. Some other features also have to be built-in in a practical
implementation of Scheme, for example, it is hard to imagine how
support for Unicode characters and strings can be loaded on demand (at
least with the Unicode SRFI I talked about at the workshop). And even
if an implementation is able to load on demand Unicode support
(because it uses a character and string representation that is
extensible at run-time), then this ***ability** is a feature of the
implementation which has a global nature (***it*** has to be
built-in). When we first started talking about SRFIs, it was this
latter kind of feature I had in mind (as I've said before, other SRFIs
such as SRFI 1, should be handled by a separate mechanism because they
are really modules that any Scheme implementation can support by
loading a portable implementation).
To accomodate implementations that wish to have as little built-in
extra stuff as possible (load on demand systems), some other mechanism
is required such as a separate configuration language (yes, specified
in another SRFI). A separate configuration language seems like an
interesting approach for load on demand systems but it is not the only
one, and I don't feel confident enough in this approach to propose it
in SRFI 0 (remember that I want SRFI 0 to last). Why do you insist on
having this in SRFI 0?
> In the present form, there's little chance that Scheme
> implementations with such a design philosophy will adopt the present
I disagree. The present draft of SRFI-0 says nothing about the
existence or absence of a configuration language or similar construct
(e.g. "import-implementation"). If some implementors feel a need for
this, there are plenty of SRFI numbers left for their proposal(s). ;-)
I'm more worried of the inverse situation. A configuration language
gives a **static** structure to the program, and this may be
incompatible with the philosophy of more dynamic Scheme
implementations that allow loading and discarding features over the
course of an interactive session. I don't want to force an
implementor to buy into a configuration language or other mechanism if
they just want to support "cond-expand" and a few SRFIs.
> - By now several Scheme implementors have expressed their preference
> for a separate configuration language. Richard, of course, Will,
> Donovan, and the Rice folks. Is there a strong reason *not* to do
> it this way?
Yes, freedom of implementation.