Per Bothner wrote:
Arthur A. Gleckler wrote:
My only concern is that an error in one part of my program should not
prevent me from running another part of the program. The thing I
most dislike about most statically typed language implementations is
that they prevent me from testing a program that isn't yet completely
type-correct when I'm not even planning to invoke the broken part of
the program. I suppose that this suggestion only allows, but doesn't
require, compiler writers to signal errors it can detect at compile
time. Still, I'd rather not encourage this behavior if it makes it
impossible to run programs that are not yet completely correct.
I really don't understand this point of view. We know that it is
*much* easier to find and fix a bug the earlier it is caught. If a
compiler can automatically find a bug right after you write it,
and you don't have to write any extra code or do any extra work,
then it seems silly to not take advantage of this help.
I would prefer a compiler not to complain about bugs I am already plenty
aware of. A bug-catching feature is only useful when it catches
something new and unknown. If I have to do extra work in order to do
some quick and dirty testing, then the compiler's bug catching features
have gotten in the way. I think that this is Arthur's POV. Perhaps you
understand it better now.
Even if a compiler can't find *all* typing errors, or even if
it isn't fully specified or consistent which errors it catches
(to address Matthias's comment) that does not negate the usefulness
any errors it *can* catch.
That is why I tend to favor requiring all variables to be lexically
declared: it makes it trivial to catch many simple mistakes.
(This does not preclude dynamic/fluid variables - they just have to
be declare as such.) Kawa has an option to warn at compile time
about unknown variables, and it's very useful option, even for Scheme.
I agree that automated bug catching is a useful tool, or a useful
option. However, perhaps it is not the job of the compiler insofar as
it is a compiler. I would favor more of a separation of concerns. Let
the compiler merely compile, and let a lint-like tool catch bugs.
Perhaps the compiler should invoke the lint, at the user's discretion,
but I don't think a standard should mandate that a compiler do anything
other than translate source code into machine code (or bytecode or
whathaveyou).
Certainly, a compiler must have some course of action which it takes
when it runs into code which it cannot translate into machine code, but
that seems not to be the issue here. It seems (upon a moderately
cursory reading of this thread) that the issue at hand is code which the
compiler could certainly compile, but which would be problematic at
runtime. Catching that is not properly the compiler's job, although it
is certainly a useful thing to do at approximately compile time. Hence
a lint would be desirable.
Regards,
Jon Wilson
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
