John
How about this:
A binding for a pattern or variable, that lacks a type signature, is treated as follows:
* At top level: polymorphic, but illegal if overloaded * Nested: monomorphic
The reason for the difference is that at top level there's no context, so forcing monomorphic is bad. Whereas for nested bindings it seems like the right thing to force a signature, which will either resolve
I thought you might be interested in this brief exchange between John and myself. (I was starting from Simon Marlow's idea of pattern binding => monomorphic.) Simon -----Original Message----- From: John Hughes [mailto:rjmh@cs.chalmers.se] Sent: 31 January 2006 14:40 To: Simon Peyton-Jones Subject: Re: mr Simon Peyton-Jones wrote: the
overloading or declare it.
Simon
I can see the attraction--it seems to "do the right thing" in each case. But aesthetically, I think it's ghastly. Now to understand a variable definition, one need not look (through the entire module) to see if it has a type signature, but also look to see whether it is top level or not! Refactoring that moves definitions in and out of where blocks (pretty common!) would also risk introducing type errors. That would be a trap for the unwary (and we were all unwary once upon a time). John