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.
Many thanks to all who're putting time into this discussion. Matthew is right in stating that we need to figure out what the "real problem" is. I always assumed an implicit agreement on this, but I've been proven wrong. I do not agree that it is clear that the real problem is modularity. (It may very well be, but then I'm not the one to judge.) The problem the past proposal(s) and revision suggestions (before Matthew's) were trying to solve was this: - How do I write a portable piece of Scheme code which depends on SRFI functionality? I'll call this "Problem SRFI" for want of a better name. This is a very narrow problem, and thus allows for a narrow solution. A solution for this does not necessarily solve the modularity problem. The idea was to *use* native solutions for the modularity problem to solve Problem SRFI. My own take on this has been that a solution for Problem SRFI needs to be expressive enough to allow for a more or less natural mapping. Translated to the realm of Scheme implementations with module systems, solving Problem SRFI means providing a way to write portable module *bodies*. A solution for the modularity problem can easily complement and extend a solution for Problem SRFI, or even replace it. The SRFI process has been designed to allow for precisely this kind of evolution. We're no longer tied to the all-or-nothing constraint of RnRS. The main problem I have with trying to solve the modularity problem in SRFI 0 is not the suitability of this or that proposal, but with the difficulty of interfacing it with existing solutions to the modularity problem, which I'm their authors are not going to be willing to abandon quite yet. (Matthew has said as much himself.) My fingers are itching to comment on Matthew's proposal (especially because I think it doesn't solve Problem SRFI), but I'd rather do this in the context of another SRFI thread. There's a deadline for SRFI 0, which has already been extended once. I have no problem with extending it again (breaking the SRFI process guidelines for this special case, if nobody disagrees), but I'd still like to wrap up a final SRFI 0 soon. If we can find a solution to the modularity problem in a separate SRFI discussion soon, we'll have lost nothing. If not, we'll have gained something anyway. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla