> 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
>   requested.

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
>   draft.

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.

Marc