I would take the view (and this may be what implicit phasing encourages) that the primary, or even sole, meaning of import is to make bindings visible. Of course this implicitly require side effects (when figuring out the values various names are bound to). Even side effects in the body of a library can have a purpose (e.g. set up data structures that the exports of the library will use), although I can't say I know a good reason for a side-effect in a library that doesn't affect its exports (what am I missing?). But "import" is not the form I would expect to do any execution. Rather, import makes bindings visible so that I can use them - if I want anything to be executed, including side-effects, I can simply use the imported bindings.
On Tue, May 5, 2009 at 3:32 PM, Michele Simionato <[email protected]> wrote: > On Tue, May 5, 2009 at 7:24 AM, Ramana Kumar <[email protected]> wrote: >> I'll admit I haven't followed your discussion of expansion-time >> side-effects in full detail. >> But I must ask what you mean to say when you write "(import (x))". >> As I understand it, an import form is not an instruction to execute >> anything, rather, it is specifying where the bindings in the following >> library or script come from. Is there anything we want to agree that >> an import form should do apart from making bindings visible (which is >> almost a conceptual thing)? If so, what would it be? > > An import form does many things: > > - at visit time/compile time, makes sintax definitions/regular bindings > visible > - at runtime, execute whatever is in the body of the module > > It can have side effects at both times. >
