Context not part of a function definition?

[Iavor S. Diatchki]

hi,

as people pointed out, you are running into the monomorphism 
restriction.  IMHO it is annoying (for exactly the kind of reason you 
point out, and it also has some unexpected semantic implications) and of 
somewhat dubious value, but here is i think why it is in the languge. 
consider the example:

let x = 1 + 2 in (x,x)

the question is how many times will "x" be evaluated.
normally one might reason as follows:
if i "pull" on the 1st component of the pair, the evaluation of "x" will 
happen (and the result will be stored for later use), and later if i 
"pull" on the 2nd component, the result will be returned immediately 
without "x" being recomputed again.  this is the idea of call by need 
evaluation (as opposed to call by name).

the thing is that since numbers in Haskell are overloaded, the 
definition above is really something like this:

let x num = (plus num) (fromInteger num 1) (fromInteger num 2) in (x,x)

i.e. x is really a function that takes as an argument a record 
containing the implementations of the numeric operations for the 
paritcular numeric type.  now since the results of function applications 
are usually not cached, this will cause "x" to be computed more than once.

the monomorphism restriction "remedies" this problem by saying that the 
overloading for bindings that "don't look like functions" (e.g. "x" 
above) should be resolvable in only one way (so that the results can be 
cached), unless an expicit type signature is present (so that the 
programmer is aware of the overloading).

often you can fix the problem by eta expanding to make things look like 
a funciton, e.g:

nub x = List.nub x

but this is annoying.


hope this helped
bye
iavor

Graham Klyne wrote:
> I'm trying to use the following idiom to selectively import functions 
> from the List module:
> 
>   import qualified List
>   nub    = List.nub
> 
> but I'm finding that HUGS complains about "unresolved top level 
> overloading" with "outstanding context:  "Eq b".
> 
> If I duplicate the type signature thus:
> 
>   import qualified List
>   nub    :: Eq a => [a] -> [a]
>   nub    = List.nub
> 
> All seems to be well.  I find it counter-intuitive that I cannot simply 
> define
> 
>   a = b
> 
> such that any occurrence of a is equivalent to an occurrence of b.  I 
> thought that was the point of referential transparency in functional 
> languages.  I don't know where to look in the Haskell documents to 
> decide whether the above is a bug or truly according to the language spec.
> 
> #g
> 
> 
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
> 
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
> 


-- 
==================================================
| Iavor S. Diatchki, Ph.D. student               |
| Department of Computer Science and Engineering |
| School of OGI at OHSU                          |
| http://www.cse.ogi.edu/~diatchki               |
==================================================