Jonathan Kraut scripsit:

> Imagine at the REPL that I request module A (via normal use of 'load'
> or some other implementation specific method).

The intention is that the normal way of loading the content of modules
is to import them.  It is as yet undefined what the effect is of loading
a file containing a module, or eval-ing a module form, or entering one
at the REPL.  The module language is not itself Scheme.

> Module A imports module B, and module B contains the call
>
>  (load "foo.scm" (interaction-environment))
>
> Then, B's exports are now available for A, and A's exports are now
> available to me. But what about any definitions from "foo.scm"? Are
> they now also available to me? If so, it seems messy, because B now
> has a signature that includes both its exports and side-effects to the
> interaction environment. And that changes A's signature as well.

I would not characterize this as a change in signature.  B has the
side effect of loading "foo.scm", but identifiers defined in "foo.scm"
are not thereby available to A, only to the interaction environment.
In principle this is no different from any other side effect, and
performing side effects in modules is always tricky because you can't
predict when or how many times they will be performed.

On reflection, there is no point in specifying any environment other
than the interaction environment to load, because it's the only standard
environment that is mutable.  I'll let the ticket stand, but add a note
to it that a second argument makes more sense as an extension.

--
John Cowan  cowan@ccil.org   http://ccil.org/~cowan
It's the old, old story.  Droid meets droid.  Droid becomes chameleon.
Droid loses chameleon, chameleon becomes blob, droid gets blob back
again.  It's a classic tale.  --Kryten, Red Dwarf

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports