The dreaded M-R

John Hughes rjmh at cs.chalmers.se
Fri Jan 27 05:38:21 EST 2006


Simon Marlow wrote:

>How about an even simpler solution:
>
>  *All* pattern and variable bindings are monomorphic unless a type
>  signature is given.
>
>I wonder how much code this would break?  ... I'd be very
>interested to tweak this in GHC and see how much code still passes the
>type checker.
>
>  
>

Now that IS an interesting idea. The more I think about it, the more I 
like it. I suspect
very few programs would break, because in many cases such a definition 
is not only
polymorphic but also overloaded, and so already carries a type signature.

Actually, I find the need to specify type signatures to get overloading 
awkward already
--but I don't think needing to do so for purely polymorphic variable 
bindings would be
significantly more awkward. I find the right context is often quite hard 
to predict, and
I want to use Hugs or GHCi to compute it rather than figure it out 
myself. Moreover,
I don't like needing to maintain such type signatures when I change code 
elsewhere.
(For example, if I've used association lists as look-up tables, then 
I'll have Eq constraints
on many definitions, and if I then change that to ordered binary trees 
then I suddenly need
to change all those Eqs to Ords. I've known cases where the work needed 
to do that
maintentance was so great that the desirable change to the program could 
not be made
within the time available for the project.) However, this is reasonably 
a separate problem,
which I don't think is made significantly worse by your idea. Perhaps 
it'll be solved
(e.g. by partial type signatures), perhaps not, but in either case I 
like your suggestion.

One more thought. Perhaps we could indicate polymorphism/monomorphism 
separately
from writing a type signature. Suppose, when we want a polymorphic or 
overloaded
variable definition, we were to write

    poly x = e

Likewise, when we want a monomorphic function definition, we could write

    mono f x y z = e

Then we could concisely indicate our intention, while leaving open the 
possibility of
using Hugs or GHCi to compute type signatures, or leaving them out to reduce
that part of the maintentance effort. Arguably, writing

    poly x = e

gives a clearer warning that something funny is going on--i.e. there is 
a risk of repeated
computation--than writing a type signature which you then have to 
examine, to see
whether or not it contains a class constraint. But of course, this idea 
would mean more
changes to existing code, adding a poly before variable definitions that 
currently carry
an overloaded type signature. Although since it would be an error to 
write such a type
signature on a definition NOT marked as poly, finding the right places 
to add it would
simply be a matter of recompiling and fixing the errors found.

The more I think about it--and recalling that a type signature need not 
be written anywhere
near the definition it refers to--the more I think using type signatures 
to carry vital
information about the *semantics* of a definition is a bad idea.

John




More information about the Haskell-prime mailing list