Re: Monomorphism & Ambiguity

[haskell-request@cs.glasgow.ac.uk]

Date: 30 May 91  4:08
From: haskell-request@cs.glasgow.ac.uk
Sender: Joe Fasel <jhf@c3serve.c3.lanl.gov>
To: haskell <haskell%cs.yale.edu@yalevm.ycc.yale.edu>
Cc: brian@c3serve.c3.lanl.gov
Subject: Re: Monomorphism & Ambiguity

Original-Via: uk.ac.nsf; Thu, 30 May 91 03:54:03 BST
Original-Sender: jhf%gov.lanl.c3.c3serve%edu.yale.ycc.yalevm@CS.YALE.edu

| Here's an example of the ambiguity problem:
|
| readPos :: String -> Integer
|
| readPos s = if n < 0 then 0 else n where
|      n = read s
|
| Here, n is referenced in two different contexts.  In the first, n < 0,
| it is completely unconstrained.  This expression can be evaluated
| for any type in class Num.  In the second reference, the `else n', n
| is constrained to be an Integer by the signature attacted to readPos.
| With monomorphism, this will force the first reference to n to also be
| Integer.  Without monomorphism, it will (I believe) default the type
| of the first reference, probably to Int.  If a non-standard class is
| involved, this would instead be a type ambiguity error.  Allowing n to
| be Int in the comparison is potentially dangerous since the read
| function will fail for the first reference if n out of the Int range
| but succeed for the second reference.

Good.  I think you have now convinced us that completely abandoning
the monomorphism restriction would not be wise.

| Now that I've defended monomorphism, let me note that the problems
| that Joe & Brian are having can and should be dealt with.  I don't
| feel that the ambiguity problem should keep us from fixing what I
| agree is a major wart in the language.  The definitions the Joe is
| concerned about do not seem to present any major problem.  I hesitate
| to endorse the type signature solution mainly because there seems to
| be the possibility of a more general solution.  In my opinion, for the
| poor unsuspecting user who writes
|
| indices = range . bounds
|
| asking for an explicit type signature is not that much better than
| adding the explicit parameter variable.  Can't we come up with a
| definition of a `safe' non-monomorphic binding that does not require
| explicit user identification?

If I understand you, you are now asking if there is a better (e.g.,
less burdensome) mechanism for allowing nonmonomorphism than the
explicit type signature.  Fine.  It isn't likely to pop up this week,
though, and our proposal is still workable.

We don't think it's so bad, by the way, for the programmer to have to
write

	indices:: (Ix a) => Array a b -> [a]
	indices = range . bounds

After all, we've established that there are some subtleties about the
class system, and the above insures that the programmer at least
knows enough about what she is doing to get the type right!

--Joe and Brian