On May 5, 2009, at 11:17 AM, Michele Simionato wrote:
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 behavior in Larceny and PLT and in general different
from the behavior in any language I know.
Being different was not a design goal of the system; you understand
that. It's a byproduct of dropping the "for" syntax from the import
form and disassociating its purpose as a scoping mechanism from its
use for instantiation.
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,
Neither the variable definitions nor the syntax definitions of FOO
use any variable or syntax exported from BAR. Yes, there is a
dependency between FOO and BAR and that's because FOO imports BAR.
But neither evaluating the syntax definitions of FOO nor evaluating
the variable definitions of FOO would cause BAR to be invoked.
even if only implicit and visible only after expansion of the macro.
Exactly. So, when the compiler sees the (FOO) library above, it
cannot decide if the imported bindings of (BAR) are going to be used
in the future or not. So, it cannot issue a warning when (FOO) is
compiled, right?
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).
That's why I gave that example, in which the visit and invoke
dependencies are not there at all, so, by your criteria, the
compiler should issue a (false) warning.
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.
1. Funny that you think a library from which you import nothing
is suspicious while a library that exports nothing, and thus
you cannot possibly import anything from, is perfectly fine.
2. Your response here does not address what you're quoting.
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.
Yet the warning persists because the compiler cannot read the
programmer's comment. :-) There is a reason why Ikarus is not
big on issuing warnings, you know. Getting the compiler to shut
up when it gives a false warning, for me, is worse than having
no warnings at all.
Anyways, we're talking about too many issues at once to make
any sense. There is debugging, refactoring imports, uninvoked
libraries, consistency with other systems, good warnings and
false warnings, and more. Can we talk about them one at a
time please so that we don't conflate one issue with another?
Aziz,,,
