[R6RS] Modules

[Michael Sperber]

Hi Kent,

thanks for clearing up the confusion---that was very helpful.

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

>> I guess I worded this in a confusing manner: My proposal says "perform
>> make" in the sense of "do automatic recompilation for a set of
>> modules."  This includes building the dependency graph, which is
>> something that make doesn't do.  The tool that does it does require
>> macro expansion.

Kent> That's right. The tool (makedepend) that does the corresponding thing for
Kent> C requires macro expansion, yet people have been getting along with C,
Kent> Make, and makedepend fine for many years.

I can't really agree that that's true---makedepend-generated
dependencies get out of synch with reality awfully often.  (And I'm
really speaking from very recent practical experience here.)  It's
sometimes hard to make makedepend do exactly what you want. This is
why many projects that use make do without makedepend.

Kent> One premise behind prohibiting abstraction of require and
Kent> provide forms seems to be that they will make programs harder
Kent> rather than easier to understand.  It's true that any kind of
Kent> abstraction can make programs harder to understand, but the
Kent> typical result is to make them easier to understand.

Here is the crux of the matter---we're in agreement about the premise,
but we're not in agreement about the typical case.  A lot of what
you've shown me as typical usage of the Chez module system where you
make use of abstraction and nesting I consider difficult to read.

The reason for this is that a REQUIRE form that's part of the regular
language is a sort of unhygienic macro by default---you can't find the
imported identifiers via the standard rules of lexical scoping.

I'm fine with introducing the ability to be unhygienic, but in a
system that has a separate configuration language, there's a clear
staging: the module system is in a separate language that can't
change, SYNTAX-RULES is always hygienic, and only for the stuff not
covered by the first two do you need SYNTAX-CASE.  That gives a clear
preference to hygiene and lexical scoping, and I conjecture that's
what people are going to use.  If you raise the convenience level of
non-hygiene, I conjecture people are going to write more unhygienic
programs, and I think that that's bad.  (Sorry for the negative
connotation of "unhygienic"---maybe somebody can suggest a better word
here.)

>> You're right that we're drawing a line here: All the exports go
>> through an (implicit or explicit) interface, where they're explicitly
>> named.  With fancy macros, you can hide the fact that you're writing a
>> definition.  However, once you want to export that definition, you
>> have to name it.  That provides the crucial bit of information we're
>> looking for.

Kent> I just don't get why this piece of information is crucial and all of the
Kent> other information you can't get so easily if you allow the use of macros
Kent> elsewhere is not crucial.

Because that bit of information is explicit, and people know exactly
where to look for it.

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