Re: [Haskell-cafe] know a workaround for greedy context reduction?
I revisited the Strongly typed Heterogeneous Lists paper and read
about the import hierarchy technique. The basic idea is to delay
importing the instances until as late as possible, which prevents the
context simplification. The instances are effectively imported in the
top, Main module.
I'm thinking of exporting a MyLibrary.Main or MyLibrary.Instances module.
Anyone have experience with this approach in a library design? Is it
worth the user's extra import? Any pitfalls?
On Sun, Dec 7, 2008 at 4:57 PM, Nicolas Frisby nicolas.fri...@gmail.com wrote:
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
simo...@microsoft.com 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: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-
| boun...@haskell.org] 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
RE: [Haskell-cafe] know a workaround for greedy context reduction?
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
Re: [Haskell-cafe] know a workaround for greedy context reduction?
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
[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
