[R6RS] Modules

[dyb at cs.indiana.edu]

> >> 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.

Most people do without makedepend because the coarse dependencies it
uncovers don't change all that often, and most large systems are built
using multiple tools, not all of which have makedepend-like utilities.
Also, while the makedepend solution is a bit fragile for C because people
often do use m4 and other tools to build up C files, a makedepend for
Scheme is likely to be more robust, especially if we don't force people
to go outside of the language to abtract over requires, etc.

> 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 code I showed you was not abtracted---it made direct use of nested
modules.  If I can use macros to create new module abstractions,
I can hide those nested modules in the abstraction, and the intent
would become more clear.  So the ability to use abstraction would have
helped, not hurt.  I claim that this is true in most cases.  If not,
or if we're petrified at the thought of an occasional bad abstraction,
we should outlaw all abstraction.

> 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.

Okay so far ...

> 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.)

... but I don't know how this argues against abstraction.  You are
again implying that abstraction could somehow make the situation worse,
but a well-designed abstraction would not do so.  In particular, an
abstraction may make the set of identifiers being imported more rather
than less clear, i.e., more rather than less "hygienic".

> >> 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.

So the information you consider crucial is crucial because it's explicit
and easily found, which is why you're arguing that we should make it
explicit and easily found.  This seems a bit circular to me, so surely
I've misunderstood your meaning.

Kent