Lazy type-class resolution

Simon Peyton-Jones simonpj at microsoft.com
Fri Aug 13 04:03:53 EDT 2004


Yes, when *inferring* types GHC defers context reduction as long as
possible.  Reason: the call site of the function may "see" more instance
declarations (e.g. in particular, overlapping ones), so doing reduction
later may yield a different answer.  

When checking the inferred type against a programmer-supplied type
signature, none of this applies; GHC looks for a proof "on the spot"
that the inferred constraints are derivable from the signature.

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org
[mailto:glasgow-haskell-users-
| bounces at haskell.org] On Behalf Of Tomasz Zielonka
| Sent: 12 August 2004 21:44
| To: GHC-users
| Subject: Lazy type-class resolution
| 
| Hello!
| 
| Recently I was trying to write a variadic function composition
operator in
| Haskell. I managed to produce a version with such an interface:
| 
|     runF (compose f1 f2 f3 ... fn)   == f1 . f2 . f3 . ... . fn
| 
| I believe it is impossible to remove 'runF' without loosing generality
| and introducing ambiguities.
| 
| But that's not my question. I noticed that Hugs can instantly infer
the nice
| type for result of composition, but GHC keeps the huge typeclass
context to
| the last moment.
| 
| __   __ __  __  ____   ___
_________________________________________
| ||   || ||  || ||  || ||__      Hugs 98: Based on the Haskell 98
standard
| ||___|| ||__|| ||__||  __||     Copyright (c) 1994-2003
| ||---||         ___||           World Wide Web:
http://haskell.org/hugs
| ||   ||                         Report bugs to: hugs-bugs at haskell.org
| ||   || Version: November 2003
_________________________________________
| 
| Hugs mode: Restart with command line option +98 for Haskell 98 mode
| 
| Type :? for help
| Prelude> :l Comp
| Comp> :t runF (compose succ (+ 1) succ read)
| runF (compose succ (flip (+) 1) succ read) :: (Num a, Enum a, Read a)
=> [Char] -> a
| Comp> :t runF (compose id id id id)
| runF (compose id id id id) :: a -> a
| 
|    ___         ___ _
|   / _ \ /\  /\/ __(_)
|  / /_\// /_/ / /  | |      GHC Interactive, version 6.2.1, for Haskell
98.
| / /_\\/ __  / /___| |      http://www.haskell.org/ghc/
| \____/\/ /_/\____/|_|      Type :? for help.
| 
| Loading package base ... linking ... done.
| Prelude> :l Comp
| Compiling Comp                ( Comp.hs, interpreted )
| Ok, modules loaded: Comp.
| *Comp> :t runF (compose succ (+ 1) succ read)
| runF (compose succ (+ 1) succ read) ::
|    forall a b a1 a2 a3 a4.
|    (MkComp (a1 -> a1)
| 	   ((a2 -> a2)
| 	    -> (a3 -> a3) -> (String -> a4) -> F a b),
|     Enum a1,
|     Num a2,
|     Enum a3,
|     Read a4) =>
|    a -> b
| *Comp> runF (compose succ (+ 1) succ read) "13123" :: Int
| 13126
| *Comp> :t runF (compose id id id id)
| runF (compose id id id id) ::
|     forall a b a1 a2 a3 a4.
|     (MkComp (a1 -> a1) ((a2 -> a2) -> (a3 -> a3) -> (a4 -> a4) -> F a
b)) =>
|     a -> b
| *Comp> let f = runF (compose id id id id)
| *Comp> :t f
| f :: forall b. b -> b
| 
| Is this a known feature of GHC ?
| 
| Best regards,
| Tom
| 
| --
| .signature: Too many levels of symbolic links
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


More information about the Glasgow-haskell-users mailing list