On Tue, May 5, 2009 at 9:43 AM, Abdulaziz Ghuloum <[email protected]> wrote:
>
> On May 5, 2009, at 8:16 AM, Michele Simionato 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.
>
> All imported modules *are* imported. Ikarus imports them before it
> goes on to doing anything.
Ok, I meant imported *and* instantiated.
>> 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.
>
> How it it lying to you?
The module will not be instantiated if not used; this is different
from the behaviour in Larceny and PLT and in general different
from the behaviour in any language I know.
> True that studying dependencies by eyeballing is a waste of time.
> Since the expander already does such analysis and records actual
> dependencies, it might make sense to expose this information to
> the user. I'll have to think about it.
I thought the compiler was smart enough to figure out even implicit
dependencies, like the one in your example:
> Should the following give a warning:
>
> (library (FOO)
> (export foo)
> (import (rnrs) (BAR) #| exports bar |#)
> (define-syntax foo
> (syntax-rules ()
> [(_) bar])))
>
> (FOO) here does not reference any of the bindings of (BAR). It
> would be absurd to print a warning, no?
It should not print a warning, because there is a dependency from BAR,
even if only implicit and visible only after expansion of the macro.
You know if the compiler is smart enough to understand that
the dependency is there; I would print a warning
only in the cases where currently the compiler ignores the dependency
(this even if you want to keep the current behavior).
> We agree that leaving unused imports in library code is a bad
> idea. Forcing such libraries to be invoked makes the problem
> worse, since you would come to expect that even libraries from
> which you import nothing, i.e., (import (only (foo))), should
> be invoked. Now you not only have to think about whether foo
> is used, but whether that import can be dropped or not based
> on whatever side effects (foo) has.
A library from which you do not import anything is suspicious and
should raise a warning. The warning would make conscious
the programmer than something strange is going on and it
would look at the library. If the import is there by accident, she would just
remove the import; if it is there because of wanted side effects,
she would add a comment near the import syntax explaining
the reason.
>> 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).
>
> For 90% of these 1% of programs, there is probably another
> solution to the problem that does not involve side effects
> and forced evaluations.
I do not disagree.
Michele
