[GHC] #1482: unsafeCoerce# doesn't always fully coerce

[GHC]

#1482: unsafeCoerce# doesn't always fully coerce
----------------------------------------+-----------------------------------
    Reporter:  yeoh at cs.wisc.edu         |        Owner:         
        Type:  bug                      |       Status:  new    
    Priority:  normal                   |    Milestone:         
   Component:  Compiler (Type checker)  |      Version:  6.6.1  
    Severity:  normal                   |   Resolution:         
    Keywords:  unsafeCoerce#            |   Difficulty:  Unknown
          Os:  Linux                    |     Testcase:         
Architecture:  x86                      |  
----------------------------------------+-----------------------------------
Comment (by sorear):

 Not a bug, but merely an extremely obscure feature of Haskell's type
 system.

 Because unsafeCoerce# does not impose a specific type upon the use of (+)
 or shows, the polymorphic type variable becomes ambiguous.  However, since
 both (+) and shows need to know the actual type of use (due to the
 implicit dictionary argument), this variable needs to be resolved somehow,
 or an error produced.

 Section 4.3.4 of the Haskell 98 Language and Libraries Report (
 [http://haskell.org/onlinereport/decls.html#sect4.3.4] ) specifies that
 ambiguous type variables are resolved using a default list, but only if
 (a) no non-standard classes are used and (b) at least one numeric class is
 used.  The idea behind this was to make numeric code easier, as even 'show
 2' would otherwise result in a type error.  Thus, in Haskell 98 (with a
 unsafeCoerce primitive), the first example is legal and the second is not
 (since defaulting does not apply unless numeric classes are involved.)
 However, even the Haskell98 defaulting rules proved somewhat too onerous
 for REPL-type situations, so GHC provides a -fextended-default-rules flag
 ( [http://haskell.org/ghc/dist/current/docs/users_guide/interactive-
 evaluation.html#extended-default-rules] ) flag to allow more cases,
 including your second one.

 Hopefully this clears things up.

 Stefan

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1482>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
-------------- next part --------------
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs at haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs