Seems I got ahead of myself with the bug search. I was thinking bug
because when I ascribe a type, I expect the compiler to check and then
respect it. With the "most general type" specification of the ":type"
command in mind, this does make sense. Thanks for improving my
internal notion of ":type".

My grumble may seem more legitimate from a library perspective. I
implement a type-level function Append with three (preferably hidden)
ancillary classes and a single instance in order to support the
multiple modalities (in the Mercury sense) of the Append logic
function. When a user defines another function that uses the append
method, it's obfuscating for the user to see the internal classes in
the inferred type. That's what I would like to workaround.

If we consider class C the internal and consider class D and the
function f the library's exposed interface, then I'd like to see C
instead of D in the context of f and any function the user defines
with f, especially when I have supplied a preferred type for f.

> f :: D a => () -> a
> f () = d

> *> :t f
> f :: (C a) => () -> a

No dice?

Thanks again,
Nick

On Sun, Dec 7, 2008 at 2:34 PM, Simon Peyton-Jones
<[EMAIL PROTECTED]> wrote:
> This is perfectly reasonable behavior I'm afraid.  If you do ":info d" you'll 
> get d's original type signature.  But ":type" takes an *arbitrary expression* 
> (in this case a single variable 'd', and figures out its most general type.  
> You could have said ":t (3*3)" for example.
>
> In this case, when inferring the most general type of the expression "d", GHC 
> tries to simplify the context (D a), and uses the instance declaration to 
> reduce it to (C a).  And then it can't simplify it further.  But you *might* 
> have had
>        instance C a
> somewhere, in which case it'd have been able to simplify the (C a) away.  So 
> GHC must try that route.  If it fails, you want it to "back up" to a 
> notationally more convenient type, but GHC can't do that, I'm afraid
>
> Simon
>
> | -----Original Message-----
> | From: [EMAIL PROTECTED] [mailto:haskell-cafe-
> | [EMAIL PROTECTED] On Behalf Of Nicolas Frisby
> | Sent: 06 December 2008 03:23
> | To: haskell Cafe
> | Subject: [Haskell-cafe] know a workaround for greedy context reduction?
> |
> | With these three declarations
> |
> |   {-# LANGUAGE FlexibleInstances #-}
> |   {-# LANGUAGE UndecidableInstances #-}
> |
> |   class C a where c :: a
> |   class C a => D a where d :: a
> |   instance C a => D a where d = c
> |
> | ghci exhibits this behavior:
> |
> |   *> :t d
> |   d :: (C a) => a
> |
> | Where I would prefer "d :: (D a) => a". In my actual examples, the
> | context is much larger and I can't involve overlapping instances. Is
> | there a known workaround? I didn't find a related bug on the GHC trac,
> | and I don't know if other compilers behave in the same way.
> | _______________________________________________
> | Haskell-Cafe mailing list
> | Haskell-Cafe@haskell.org
> | http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to