R. Kent Dybvig
Sun Aug 22 13:58:51 EDT 2004
> 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:
(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
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
More information about the R6RS