-fno-monomorphism-restriction makes type-inference ambiguous?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

-fno-monomorphism-restriction makes type-inference ambiguous?

Eike Scholz
Note: This Question has already been asked on the haskell mailing list.
      But haskell-cafe seems to be more adequate for for this question.

Hi,

i have encountered a problem and I don't quite understand
the reason why I get the results I get.
ghci seems to infer different types for the same expression.

Consider that I have disabled the monomorphism restriction
in module AGC.lhs (which is attached).

and I have a toplevel definition of:

> mylength = synAttr listLength

loding the module in ghci (6.4) gives (beside some correct warnings):

$ Ok, modules loaded: Main.
$ *Main> :type synAttr
$ synAttr :: (Data b) => ((?stack::[Dyn]) => b -> a) -> Attr a

$ *Main> :type listLength
$ listLength :: (?stack::[Dyn]) => List -> Float

$ *Main> :type (synAttr listLength)
$ (synAttr listLength) :: Attr Float

$ *Main> :type mylength
$ mylength :: (?stack::[Dyn]) => Dyn -> Dyn -> [Dyn] -> Maybe Float

$ *Main> let mylength = synAttr listLength
$ *Main> :type mylength
$ mylength :: Dyn -> Dyn -> [Dyn] -> Maybe Float

where

> type Attr a = Dyn -> Dyn -> [Dyn]-> Maybe a

the problem I have is that inferred types for the toplevel declaration
mylength differ from the verbatim equal definition in the Let
experssion.

for the toplevel it infers:

  mylength :: (?stack::[Dyn]) => Dyn -> Dyn -> [Dyn] -> Maybe Float

for the let-Binding
 
  mylength :: Dyn -> Dyn -> [Dyn] -> Maybe Float

and this is what I expected.

Has anyone an Idea, why this happens?

best regards,

  Eike Scholz

PS: Beware of the comments in the attached file. This file is under
heavy development. I am dyslexic and don't correct the comments
while continuously rewriting code and comments. I hope that the comments
are useful anyway.
The (+>) (~>) (#>) operators are broken at the moment and don't work the
way intended.







_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

AGC.lhs (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: -fno-monomorphism-restriction makes type-inference ambiguous?

Ben Rudiak-Gould
Eike Scholz wrote:

>> mylength = synAttr listLength
>
> $ *Main> :type synAttr
> $ synAttr :: (Data b) => ((?stack::[Dyn]) => b -> a) -> Attr a
>
> $ *Main> :type listLength
> $ listLength :: (?stack::[Dyn]) => List -> Float
>
> $ *Main> :type (synAttr listLength)
> $ (synAttr listLength) :: Attr Float
>
> $ *Main> :type mylength
> $ mylength :: (?stack::[Dyn]) => Dyn -> Dyn -> [Dyn] -> Maybe Float
>
> where
>
>> type Attr a = Dyn -> Dyn -> [Dyn]-> Maybe a

This may be a bug. But note that both interpretations are legitimate. One
way of applying synAttr to listLength is first to apply ?stack to
listLength, obtaining listLength' :: List -> Float and creating a
(?stack::[Dyn]) constraint on the application node, then specializing
listLength' to the type (?stack::a) => List -> Float, then passing that to
synAttr.

Again, I recommend that you not try to use implicit parameters.

-- Ben

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe