[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI 0 philosophy

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

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

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

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