[R6RS] modules

[R. Kent Dybvig]

> Specifically, couldn't the issue of stale requires be easily solved
> with a tool?

A tool can determine if the requires are necessary for a particular build,
but it cannot necessarily determine whether a require can be eliminated
from the source code, since a change in an imported syntactic abstraction
can affect whether other module imports are used.  For example, does
(a x) reference x?  We can answer this question for a particular
definition of a but not for all possible definitions of a.

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

Here's a simple one:  Suppose I want to make sure I get the r6rs cons
and not some other cons, so I write:

  ((let () (require scheme) cons) x y)

With top-level require only, I would write:

  (module ---
    (require (add-prefix scheme "real:"))
    ---
                   (real:cons x y)
    ---)

I think the former is clearer, but others may not.  (Plus, I don't have
to think of a prefix or remember what it was.)

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

Not at all.  I'm not sure how I gave that impression, but I would
certainly want local imports to shadow local bindings.  Modules create
sets of bindings; require forms make them visible.

> ... However, I don't think this is a good reason against *writing*
> down the "user part" of the interface.

Again, no problem, but I'd prefer not to have to when I don't want to.

> (As you can see, a lot of my issues have to do with the clarity of the
> code I expect people to write. ...

As do mine.  I am also concerned about convenience and maintainability,
as I'm sure you are as well.

> ... Also, the component system issue still
> lurks in the back of my mind.)

Just as local modules still lurk in the back of mine, but we have agreed
to focus on the top-level module issue for now independent of these
other issues.

Kent