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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
