On Feb 26, 2007, at 12:11 AM, Per Bothner wrote:
Jon Wilson wrote:
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.
I understand it, but it seems an amateurish way of working.
If you have a bug you're plenty aware of, it's almost always easy to
fix it at least to the extent of shutting up the compiler. After all,
people do that every day in C and C++.
Yes, and people waste an amazing amount of time in C, C++, and Java
because of the need to satisfy the compiler in cases like this.
Remember, when one changes a program from one completely working
state to another, one always moves through a large number of non-
working states, e.g. when the numbers of parameters don't match,
etc. If I'm experimenting with a new signature for a procedure, why
can't I test one body of code that uses it, a body in which I've
changed the calls, without changing every single call in the entire
code base? If I find out that the new signature was a bad idea, I'd
like to be able to revise my design without once again modifying
every call in the entire code base for the compiler's benefit, not mine.
We've already dropped one of the core features of the language, its
REPL, from the specification. Let's not go any further and lose the
prototyping-friendly nature of the language.
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
