[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SRFI 0 philosophy [WAS: logical operations in if-implements]
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:
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.
In an implementation which provides all of its features by default
(like Gambit-C), the implementation of
(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.
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