RE: Lazy type-class resolution
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: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] 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: [EMAIL PROTECTED] | || || 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 | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Lazy type-class resolution
Yes, lazy type-class resolution is a known GHC feature - and in my opinion much superior to Hugs stict type class resolution. Hugs can get confused with overlapping instances and will choose the wrong instance because it commits too early. GHC does not suffer from this. Keean. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Lazy type-class resolution
On Fri, Aug 13, 2004 at 09:03:53AM +0100, Simon Peyton-Jones wrote: 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. Thanks for explanation. Besides overlapping instances, what are the other mechanisms that could change the decision later? I can't think of any, are they only hypotetical? Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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: [EMAIL PROTECTED] || || 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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Lazy type-class resolution
I forgot to attach the code. Here it is.
Tom
--
.signature: Too many levels of symbolic links
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
module Comp where
newtype F a b = F { runF :: a - b }
class Fun f a b | f - a, f - b where
apply :: f - a - b
instance Fun (a - b) a b where
apply f x = f x
class MatchFun a b f | f - a, f - b where
wrapF :: f - F a b
instance MatchFun a b (a - b) where
wrapF f = F f
class MkComp a b where
compose :: a - b
instance MatchFun a b f = MkComp f (F a b) where
compose f = wrapF f
instance ( Compose r f a b
, MkComp (a - b) t
, Fun r b1 b
, Fun f a b1 ) = MkComp r (f - t)
where
compose r f = compose (comp r f)
class Compose t f a b | t f - a, t f - b where
comp :: t - f - a - b
instance (Fun t b c, Fun f a b) = Compose t f a c where
comp t f x = apply t (apply f x)
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
