why is this legal

Antony Courtney antony@apocalypse.org
Sat, 02 Feb 2002 10:03:20 -0500

David Feuer wrote:

>>From: Hal Daume III <hdaume@ISI.EDU>
>>then, why are we allowed to rebind f in a let clause :)
> 1. There is no real reason not to allow this, 

Hmmm.  I thought Hal gave a fairly real reason:

   f x = f' 0 x
       where f' acc [] = acc
             f acc (x:xs) = f' (x+acc) xs

This example has a notoriously difficult to spot one character typo that 
causes the whole program to do something other than what the programmer 
intended at runtime.

 > so such a

> rule would just limit the flexibility of the language and 
> annoy programmers.  It would also make it somewhat harder 
> to write compilers, because they would have to check 
> uselessly for violations of an extra rule.

You know, this is exactly the kind of argument used by a Scheme 
programmer to tell us why static type systems are bad.  :-)

I hope you share my (subjective) view that such complaints are bogus if 
we are talking about static type systems.  If so, and if you will 
forgive a terrible pun, why do you think it's ok for the compiler to 
catch type errors, but not typing errors?  (*GROAN*....couldn't resist, 

 > 2. It increases the ability to move code around without
 > changing it.  For example, suppose you have
 > [...]
 > There is another, possibly more significant reason,
 > however:  sometimes it is very nice to be able to "shadow"
 > an external variable

Yes, these are all valid uses, which is why I would favor having the 
compiler emit a warning in such circumstances.

Interestingly, this is exactly what gcc does if you shadow a parameter 
with a local variable in a function in C:

int f(int y) {
   int y = 20;

   return y + 10;

$ gcc -c shadow.c
shadow.c: In function `f':
shadow.c:4: warning: declaration of `y' shadows a parameter

Many in the Haskell community disagree with me, but I find compiler 
warnings such as the above immensely helpful.  They are a way for the 
compiler to say to the programmer, "Your program has a reasonable 
meaning, but you used some dangerous construct so that what you said 
might not have been what you meant."

Of course, good compilers/tools will let you turn such warnings on and 
off selectively, and good programmers write programs that compile 
without warnings (since warnings usually indicate dubious constructs).
While the examples you give are valid, I'm not convinced they are common 
enough that a warning would become a nuisance.



Antony Courtney
Grad. Student, Dept. of Computer Science, Yale University
antony@apocalypse.org          http://www.apocalypse.org/pub/u/antony