This page is part of the web mail archives of SRFI 0 from before July 7th, 2015. The new archives for SRFI 0 contain all messages, not just those from before July 7th, 2015.
Hi Marc, I'll answer this slightly out of sequence. >>>>> "Marc" == Marc Feeley <feeley@xxxxxxxxxxxxxxxx> 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