Hi Marc,

I'll answer this slightly out of sequence.

>>>>> "Marc" == Marc Feeley <xxxxxx@IRO.UMontreal.CA> writes:

Marc> [ binding-time problems ]

I think we editors have pretty much adopted Richard's view that the
whole feature business should happen in a separate configuration
language.  His message is at:

http://srfi.schemers.org/srfi-0/mail-archive/msg00020.html

I'll be happy to put together a new revision suggestion (Richard's
refers to ours) if anyone tells me to.

Marc> I just don't see how this non-determinism can actually be helpful in
Marc> real programs.

Since everybody except us editors seems to be set against
non-determinism, I won't be too sad to see it go.  (After all, what
good is specifying it if nobody implements it?)  I can't speak for
Shriram and Dave on this, though.

Marc> The question I ask is why should all of this be in SRFI-0?  Why not
Marc> leave it to some other SRFI, so that SRFI-0 can be lean and simple.
Marc> In particular, I see lots of overlap in functionality between
Marc> IMPORT-IMPLEMENTATION/IMPORT-READER-SYNTAX and a module system, so its
Marc> probably best to work on a general module system SRFI than on the
Marc> relatively crippled IMPORT-IMPLEMENTATION/IMPORT-READER-SYNTAX.

There are several arguments here.  I'll try to pick them apart.

- Simplicity:
  In an implementation which provides all of its features by default
  (like Gambit-C), the implementation of
  IMPORT-IMPLEMENTATION/IMPORT-READER-SYNTAX
  (or Richard's equivalents of them) is absolutely trivial.  (No-ops,
  essentially.)  I think the overhead of implementing them is minimal
  in these implementations as compared with vanilla IF-IMPLEMENTS.

- Necessity:
  Not all implementations work the same way as Gambit.  For example,
  MzScheme and Scheme 48 have most of its functionality hidden in
  modules (or their local equivalents) loaded/linked on demand.
  Therefore, SRFI 0 should provide a way for the programmer to tell
  the implementation what to load on-demand or open.  Otherwise, SRFI
  0 will not be very useful in these implementations.

- Module system:
  Unfortunately, a general module system is far away.  However,
  Richard's proposal maps easily to all Scheme module systems I know.
  It also works entirely without one.

So, in conclusion, I don't think leanness and simplicity is
sacrificed by making SRFI 0 more elaborate.  I think making SRFI 0
more elaborate is necessary to make it sufficiently useful.

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