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?
On Tue, May 5, 2009 at 3:16 PM, Michele Simionato <[email protected]> wrote: > When I first heard that non-used modules are not imported in Ikarus > my gut reaction was negative. I saw various issues with that approach. > > The first issue is that what I write is not what I get: if I write > (import (x)) I expect the module x to be imported and I do not want > the compiler to lie to me. > > The second issue is that a programmer reading the import line will > assume that something comes from module x (even if the module is not > actually used) and will waste time studying module x before realizing > that all of its exported bindings are not used. > > Importing a module which is not used 99% of the times is a consequence > of refactoring: the dependency was used in the first version of the > script, or was used during development, and you forgot to drop it from > the import list. This happens to me all the time in Python, and I > solve the issue by using pylint, a tool that warns me about unused > modules. > > In general, I think the right thing to do with unused modules is to > print a compiler warning and to import them anyway. > If you silently ignore unused modules, and people rely on this > feature, the risk is to litter many programs with unused imports > which will just confuse your readers. > > Finally, there the issue of modules which are just imported for > side effects. This happens 1% of the times, is tricky, I did not think > of it and I realized only yesterday the consequences (basically, it > makes it harder to use Matthew Flatt's trick to manage side-effects > at compile time). > > On this point I do not have a clear mind (do I want to rely on side > effects at compile time across modules?). However, the previous > points stand out: the compiler should do as I ask and instantiate a module, > even if the only thing the module does is to print a debugging message. > > Curious to know what others think of this issue, > > Michele Simionato >
