[R6RS] modules

[Michael Sperber]

>>>>> "Kent" == R Kent Dybvig <dyb at cs.indiana.edu> writes:

>> I guess I'm a bit disappointed that you didn't take up any (that I
>> could see) of my arguments in the thread between Matthew and myself.

Kent> That is unfortunate, and it may be that we just don't understand your
Kent> point of view, much as I didn't understand some of Matthew's until we
Kent> spoke.  Perhaps we'll have better luck when we meet in person.  Email is
Kent> great, but it's often a poor substitute for interactive communication.

Many thanks for your reponse---I believe we're making progress.  Sorry
if I sounded negative---that wasn't my intention.

Kent> No one has introduced a local module construct.  

Ah, I guess I just automatically assumed that.  That immediately
clears up a lot of the immediate gripes I have with your
proposal---thanks for clarifying!

>>  * Require forms should be allowed in arbitrary local scopes to provide
>>    finer control over visibility.  Local require forms can also help
>>    prevent stale requires (requires that were once needed for a small
>>    portion of the module that has since been removed or rewritten).
>>    They can also obviate some renaming of imports.

That's fine in the abstract, but I really have a hard time seeing how
that translates into practice---I've been hacking with the Scheme 48
and MzScheme module systems for probably ten years now without missing
local imports.

Specifically, couldn't the issue of stale requires be easily solved
with a tool?  Also, I'd say that the import renaming can either be
done at the top-level, or (in the scenario where the local import is
specifically useful) should be done anyway to avoid confusion for the
reader.

The latter point I guess is my main gripe: Local bindings are
introduced without naming them at that place in the source code.  I
think requiring them to be named forces some amount of readability.

Thus, I would really like to see some concrete examples here.

Let me say where I think local imports would be useful, but where I'm
still debating with myself whether they're worth the cost

I work often with embedded DSLs.  One (reactive programming) has
operations like "+" "sin" and so on, where writing down "+!", "sin!"
(or some such) is tedious.  Another (financial contracts) has
operations "and", "or", "+", "-" and so on---same thing.  It would be
useful to say, for a local scope, "when I say +, I mean something
different."  On the other hand, you seem to be saying that you'd like
to preclude precisely this case.  (Shadowing local bindings with local
imports.)

>> - separate interfaces

Kent> As I said in my note, I do not wish to preclude separate
Kent> interfaces, but I don't think they are useful enough to require
Kent> the extra syntactic overhead in all cases.

I guess you're right: The issue of *requiring* them mainly comes up in
component systems when you're linking interfaces by name.  However,
the *ability* to have them is very useful in the absence of that,
mainly because it allows somewhat clearer and more readable
construction of interfaces.  (In Scheme 48, most interfaces have
names, but some don't.)

Kent>   * Any specification of an interface without syntax definitions (if any)
Kent>     is incomplete, i.e., won't support independent compilation or
Kent>     analysis.  While separate interfaces can be useful documentation,
Kent>     a tool that examines (expands and scans or analyzes) a module can
Kent>     provide even better information on demand (as well as the information
Kent>     necessary to separately compile dependent modules and applications).

Yes.  That's the point I most sympathize with.  But I think this
mainly says that the interface the user writes down is something
different from the one the implementation uses for purposes like
independent compilation, and they probably shouldn't both be called
"interfaces."  Conceptually, of course, for things like matching
interfaces to each other, the macro definitions need to be part of
them.  However, I don't think this is a good reason against *writing*
down the "user part" of the interface.

(BTW, Martin Gasbichler is, for his thesis, working on a module system
with exactly this property.  This also enables Alan-Bawden-style
first-class macros in a very natural manner.)

(As you can see, a lot of my issues have to do with the clarity of the
code I expect people to write.  Also, the component system issue still
lurks in the back of my mind.)

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla