Hi Marc,

many thanks for the prompt reply!

>>>>> "Marc" == Marc Feeley <xxxxxx@iro.umontreal.ca> writes:

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

Marc> That is not true.  "cond-expand" has to be built-in.

I probably wasn't clear enough.  Of course, COND-EXPAND has to be
built-in for SRFI-dependent code to be loaded.  By implication, SRFI 0
itself is not I feature I'd have to request, therefore.  There's no
reason why any of the other features would have to be built-in.

Marc> So implementors have to add some built-in support in their
Marc> implementation to use SRFIs.  Some other features also have to
Marc> be built-in in a practical implementation of Scheme, for
Marc> example, it is hard to imagine how support for Unicode
Marc> characters and strings can be loaded on demand (at least with
Marc> the Unicode SRFI I talked about at the workshop).  And even if
Marc> an implementation is able to load on demand Unicode support
Marc> (because it uses a character and string representation that is
Marc> extensible at run-time), then this ***ability** is a feature of
Marc> the implementation which has a global nature (***it*** has to be
Marc> built-in).  When we first started talking about SRFIs, it was
Marc> this latter kind of feature I had in mind

Sure.  At the very least, this is something that needs to be stated
very explicitly in the SRFI.  It seems the main communication problem
we're having right now is that we see different kinds of SRFIs to be
under the purview of SRFI 0.

Marc> (as I've said before, other SRFIs such as SRFI 1, should be
Marc> handled by a separate mechanism because they are really modules
Marc> that any Scheme implementation can support by loading a portable
Marc> implementation).

Exactly.  As it has turned out, all SRFIs proposed so far, except for
the uniform-vector proposal, *are* "other" SRFIs.  It's not that there
isn't a case to be made for differentiating between these kinds of
SRFIs---it's just that both the editors' as well as Richard's proposal
address both with a minimum of additional overhead.  In fact, in an
implementation where everything's built-in, explicit import just
reduces to a no-op.  So why not put it in?

Marc> To accomodate implementations that wish to have as little built-in
Marc> extra stuff as possible (load on demand systems), some other mechanism
Marc> is required such as a separate configuration language (yes, specified
Marc> in another SRFI).  A separate configuration language seems like an
Marc> interesting approach for load on demand systems but it is not the only
Marc> one, and I don't feel confident enough in this approach to propose it
Marc> in SRFI 0 (remember that I want SRFI 0 to last).  Why do you insist on
Marc> 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.

Marc> I disagree.  The present draft of SRFI-0 says nothing about the
Marc> existence or absence of a configuration language or similar construct
Marc> (e.g. "import-implementation").  If some implementors feel a need for
Marc> this, there are plenty of SRFI numbers left for their proposal(s). ;-)

Requiring these implementors to add a separate configuration language
would entail two things, however:

- A user would have to duplicate information, because SRFIs needed by
  the code would have to be imported elsewhere.
- Software dependent on SRFIs can no longer be shipped in a portable
  way.

Admittedly, neither of these is necessary, but I think they're both
desirable.

Marc> I'm more worried of the inverse situation.  A configuration language
Marc> gives a **static** structure to the program, and this may be
Marc> incompatible with the philosophy of more dynamic Scheme
Marc> implementations that allow loading and discarding features over the
Marc> course of an interactive session.

This is not impaired by a separate configuration language: We cannot
really take away SRFIs used by code already loaded because COND-EXPAND
is static.  We can absolutely take away SRFIs from code loaded in the
future.

The specification of a separate configuration language in no way
requires an Scheme system to actually implement it that way; it just
requires a syntactic binding to introduce a program dependent on
SRFIs.  Richard's suggestion was simply PROGRAM, I believe.

Marc> I don't want to force an
Marc> implementor to buy into a configuration language or other mechanism if
Marc> they just want to support "cond-expand" and a few SRFIs.

But the overhead of the configuration language is absolutely trivial
for these folks.  Everything but COND-EXPAND just reduces into a no-op.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla