[Haskell-cafe] Understanding GHC's instance inference.

19 views
Skip to first unread message

Takayuki Muranushi

unread,
Dec 5, 2012, 12:12:36 AM12/5/12
to haskell
Dear everyone,

I have a code
https://github.com/nushio3/practice/blob/master/instance-inference/zipf-11-1.hs

that produces a type-error when I remove a type signature.
https://github.com/nushio3/practice/blob/master/instance-inference/zipf-11.hs

The strange point is the following error message from ghc 7.6.1
(abbreviated; the full error text is included as the comment of the
code):

No instance for (PType
(Cons
V.Vector
(V.Vector Double)
(Cons
V.Vector
(V.Vector Char)
(Cons V.Vector (V.Vector Int) (Nil V.Vector))))
((Double -> Char -> Int -> String) -> a0))
arising from a use of `forZN'
The type variable `a0' is ambiguous
Possible fix: add a type signature that fixes these type variable(s)
Note: there is a potential instance available:
instance [overlap ok] (Zip v, Reduce v f0 vaS r (Nil v)) =>
PType (Cons v (v i) vaS) ((i -> f0) -> v r)



ghc presents only one potential instance, and it seems to me that by setting
v = V.Vector
i = Double
f0 = Char -> Int -> String
r = String

etc, you can actually match the 'potential' instance. The fact that
this code typechecks with an additional type signature (zipf-11-1.hs)
shows that there is a way to satisfy the constraint. So the question:
why the instance inference stops here, when there is only one
potential instance and no ambiguity? Or is it? What are potential
instances?

I thought the cause of the error is that ghc cannot match (v r) with
(a0), and so I tried to shrink the example before I post. However my
guess was wrong. Tinyer example did typecheck:

https://github.com/nushio3/practice/blob/master/instance-inference/copy-01.hs
https://github.com/nushio3/practice/blob/master/instance-inference/copy-02.hs
https://github.com/nushio3/practice/blob/master/instance-inference/copy-04.hs

If you have any sample codes that fails to typecheck and presents only
one "potential instance" , that will be a great clue for me. Also,
please recommend me any reading material for instance inference.
(Haskell 98 deals with instance declaration syntax, and there are
variety of text for type inference, but I could find few for instance
inference.)


Best,
--
Takayuki MURANUSHI
The Hakubi Center for Advanced Research, Kyoto University
http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

adam vogt

unread,
Dec 5, 2012, 7:00:46 PM12/5/12
to haskell-cafe
On Wed, Dec 5, 2012 at 12:12 AM, Takayuki Muranushi <mura...@gmail.com> wrote:
> Dear everyone,
>
> I have a code
> https://github.com/nushio3/practice/blob/master/instance-inference/zipf-11-1.hs
>
> that produces a type-error when I remove a type signature.
> https://github.com/nushio3/practice/blob/master/instance-inference/zipf-11.hs

Hi Takayuki,

The ghc manual sections about the extensions are a good place to
start. Also check out http://okmij.org/ftp/Haskell/

I think you are expecting forZN to be able to use the number of -> in
the function(s) supplied to decide how many lists to take, as done
here: http://paczesiowa.blogspot.ca/2010/03/generalized-zipwithn.html

Replacing the [] container used in the above zipWithN with a
`Data.Key.Zip v => v' that is the same for all of the arguments might
be straightforward. But there are a lot of type signatures that have
to add that parameter, and maybe that will interfere with the
incoherent instance business going on.

Adam

Takayuki Muranushi

unread,
Dec 7, 2012, 9:12:25 PM12/7/12
to adam vogt, haskell-cafe
Thank you, Adam,

for I didn't know about paczesiowa's article. That will be useful for me.

What I was trying to make is a zipWithN that takes the zipper function
as its "last" argument, not the first. This is because in my
applications the zipper functions tend to be complicated lambdas, as
illustrated in [1] . Since we live in curried world where all
functions are superficially unary, to define the "last" argument, and
to implement forZN, needs extra work than to implement zipWithN, I
believe [2] . I'm interested how much we can make these two share
their internal mechanisms.


[1] https://github.com/nushio3/practice/blob/master/free-objects/zipf-05.hs
[2] https://groups.google.com/forum/?fromgroups=#!topic/haskell-cafe/-e-xaCEbd-w

2012/12/6 adam vogt <vogt...@gmail.com>:
--
Takayuki MURANUSHI
The Hakubi Center for Advanced Research, Kyoto University
http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

Reply all
Reply to author
Forward
0 new messages