monomorphism and ambiguity

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

Date: 29 May 91 22:43
From: haskell-request@cs.glasgow.ac.uk
Sender: Satish Thatte <satish@sun.mcs.clarkson.edu>
To: haskell@cs.yale.edu
Subject: monomorphism and ambiguity

Original-Via: uk.ac.nsf; Wed, 29 May 91 22:26:39 BST

John Peterson writes:

	I think Joe over-simplifies the issue by bringing up the
	 re-evaluation aspect.  The real issue has to do with the 
	semantics of the definition mechanism.  Consider the following:

		x = exp
		y = ... x ...
		z = ... x ...

	We would expect x to be bound to exactly the same value in 
	both y and z; this is the heart of the monomorphism argument. 
	Without it, there is no way to be sure that the two references 
	to x yield the same value.  This is what leads to ambiguity and 
	loss of a fundamental abstraction property.

I can't see why this leads to either ambiguity or to loss of 
abstraction.  Haskell allows this when "x" is "+", so what is the 
difference if "x" is not bound to a lambda abstraction?  Aren't 
functions first-class values?  For that matter, is "x" is defined as

x = ((+),(*))
x :: Num a, Num b => (a -> a -> a, b->b->b)

and used at different instances of Num, why is this ambiguous?
John, could you elaborate your point please?

Satish