Is this a GHC bug? Problem inferring type

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

Is this a GHC bug? Problem inferring type

Peter Hall
This is confusing me, and I'm wondering if it's a compiler bug. I have this:

   foo = (++) `on` show

I'm expecting the type to be:

    foo :: Show a => a -> a -> String

But GHCI is inferring:

    foo :: () -> () -> String


If I explicitly provide a type annotation, or if I use
-XNoMonormorphismRestriction, then it all works fine. I would expect a
compile error if the type couldn't be inferred due to the Monomorphism
Restriction, but instead it has silently chosen the least useful type.

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130608/a47f2c28/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Is this a GHC bug? Problem inferring type

Brandon Allbery
On Sat, Jun 8, 2013 at 9:02 AM, Peter Hall <peter.hall at memorphic.com> wrote:

> This is confusing me, and I'm wondering if it's a compiler bug. I have
> this:
>
>    foo = (++) `on` show
>
> I'm expecting the type to be:
>
>     foo :: Show a => a -> a -> String
>
> But GHCI is inferring:
>
>     foo :: () -> () -> String
>

No bug; it's the monomorphism restriction combining with extended
defaulting to infer a monomorphic type. If you want to keep the
monomorphism restriction and throw a type error, disable
ExtendedDefaultRules.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130608/3c65d193/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Is this a GHC bug? Problem inferring type

Peter Hall
Ah, thanks for the explanation. I hadn't heard of ExtendedDefaultRules
before.

Peter


On 8 June 2013 14:35, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Sat, Jun 8, 2013 at 9:02 AM, Peter Hall <peter.hall at memorphic.com>wrote:
>
>> This is confusing me, and I'm wondering if it's a compiler bug. I have
>> this:
>>
>>    foo = (++) `on` show
>>
>> I'm expecting the type to be:
>>
>>     foo :: Show a => a -> a -> String
>>
>> But GHCI is inferring:
>>
>>     foo :: () -> () -> String
>>
>
>  No bug; it's the monomorphism restriction combining with extended
> defaulting to infer a monomorphic type. If you want to keep the
> monomorphism restriction and throw a type error, disable
> ExtendedDefaultRules.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130608/e4928352/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Is this a GHC bug? Problem inferring type

Michael Peternell
In reply to this post by Brandon Allbery
in my opinion this is a bug of ghc. maybe the implementation works exactly as it should, according to the specification: then it's a bug in the specification.

Show a => a -> a -> String
just makes much much more sense than
() -> () -> String
which makes no sense at all imho

and i think it would be possible to infer the type in this case.

++ :: [a] -> [a] -> [a]
show :: Show e => e -> String
on :: (b -> b -> c) -> (d -> b) -> d -> d -> c

on (++) show :: d -> d -> c
(++) :: [a] -> [a] -> [a] = b -> b -> c
-> b = c = [a]
show :: Show e => e -> String = (d -> b)
-> b = String, Show d
-> c = String, a = Char

on (++) show :: Show d => d -> d -> String

is it really not possible to write an algorithm that can deduce this kind of stuff?

Am 08.06.2013 um 15:35 schrieb Brandon Allbery <allbery.b at gmail.com>:

> On Sat, Jun 8, 2013 at 9:02 AM, Peter Hall <peter.hall at memorphic.com> wrote:
> This is confusing me, and I'm wondering if it's a compiler bug. I have this:
>
>    foo = (++) `on` show
>
> I'm expecting the type to be:
>
>     foo :: Show a => a -> a -> String
>
> But GHCI is inferring:
>
>     foo :: () -> () -> String
>
> No bug; it's the monomorphism restriction combining with extended defaulting to infer a monomorphic type. If you want to keep the monomorphism restriction and throw a type error, disable ExtendedDefaultRules.
>
> --
> brandon s allbery kf8nh                               sine nomine associates
> allbery.b at gmail.com                                  ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners



Reply | Threaded
Open this post in threaded view
|

Is this a GHC bug? Problem inferring type

Brandon Allbery
On Sat, Jun 8, 2013 at 2:54 PM, Michael Peternell
<michael.peternell at gmx.at>wrote:

> in my opinion this is a bug of ghc. maybe the implementation works exactly
> as it should, according to the specification: then it's a bug in the
> specification.
>
> Show a => a -> a -> String
>

...is not monomorphic. If you want that to be inferred, turn off the
monomorphism restriction. (And yes, many people *do* consider the
monomorphism restriction of standard Haskell to be a bug in the
specification.)

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130608/15585ae7/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Is this a GHC bug? Problem inferring type

Peter Hall
>
>> Show a => a -> a -> String
>>
>
> ...is not monomorphic. If you want that to be inferred, turn off the
> monomorphism restriction. (And yes, many people *do* consider the
> monomorphism restriction of standard Haskell to be a bug in the
> specification.)
>
>
When are we due a new spec? 1998 was quite a while ago...

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130608/3c240a50/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Is this a GHC bug? Problem inferring type

Graham Gill
On 08/06/2013 4:11 PM, Peter Hall wrote:

>
>
>         Show a => a -> a -> String
>
>
>     ...is not monomorphic. If you want that to be inferred, turn off
>     the monomorphism restriction. (And yes, many people *do* consider
>     the monomorphism restriction of standard Haskell to be a bug in
>     the specification.)
>
>
> When are we due a new spec? 1998 was quite a while ago...
>
> Peter

2010 <http://www.haskell.org/haskellwiki/Haskell_2010>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130608/498769a1/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

Is this a GHC bug? Problem inferring type

Peter Hall
Oops :)




On 8 June 2013 21:15, Graham Gill <math.simplex at gmail.com> wrote:

>  On 08/06/2013 4:11 PM, Peter Hall wrote:
>
>
>
>>> Show a => a -> a -> String
>>>
>>
>>  ...is not monomorphic. If you want that to be inferred, turn off the
>> monomorphism restriction. (And yes, many people *do* consider the
>> monomorphism restriction of standard Haskell to be a bug in the
>> specification.)
>>
>>
>  When are we due a new spec? 1998 was quite a while ago...
>
>  Peter
>
>
> 2010 <http://www.haskell.org/haskellwiki/Haskell_2010>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130608/49aec637/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Is this a GHC bug? Problem inferring type

Brandon Allbery
In reply to this post by Peter Hall
On Sat, Jun 8, 2013 at 4:11 PM, Peter Hall <peter.hall at memorphic.com> wrote:

> Show a => a -> a -> String
>>>
>>
>> ...is not monomorphic. If you want that to be inferred, turn off the
>> monomorphism restriction. (And yes, many people *do* consider the
>> monomorphism restriction of standard Haskell to be a bug in the
>> specification.)
>>
>>
> When are we due a new spec? 1998 was quite a while ago...
>

Most recent spec was Haskell 2010, as pointed out by someone else. There is
some talk of pushing for a 2014 revision which would include (among other
things) removal of the monomorphism restriction ? but the standards
committee is notoriously conservative, and IIRC argued against that
proposal in 2010.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130608/6966faac/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Is this a GHC bug? Problem inferring type

Peter Hall
>
>
> Most recent spec was Haskell 2010, as pointed out by someone else. There
> is some talk of pushing for a 2014 revision which would include (among
> other things) removal of the monomorphism restriction ? but the standards
> committee is notoriously conservative, and IIRC argued against that
> proposal in 2010.
>


But there has a been a lot of momentum in recent years towards removing it.
Aren't we a little optimistic? Presumably the only objection is the feeling
that it raises the barrier of difficulty for new implementations?

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130609/ed7d40d1/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Is this a GHC bug? Problem inferring type

Brandon Allbery
On Sat, Jun 8, 2013 at 8:16 PM, Peter Hall <peter.hall at memorphic.com> wrote:

> Most recent spec was Haskell 2010, as pointed out by someone else. There
>> is some talk of pushing for a 2014 revision which would include (among
>> other things) removal of the monomorphism restriction ? but the standards
>> committee is notoriously conservative, and IIRC argued against that
>> proposal in 2010.
>>
>
> But there has a been a lot of momentum in recent years towards removing
> it. Aren't we a little optimistic? Presumably the only objection is the
> feeling that it raises the barrier of difficulty for new implementations?
>

No. The original reason for it is that one typically gives a constant
applicative form (a binding without a function arrow; informally, a
"value") a name so that it can be shared ? but a polymorphic value cannot
be shared. (See, for example, the various tricks for memoizing the
Fibonacci series; these rely on the list being shared, both in its own
definition and when it is used.)

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130609/fa04cea9/attachment.htm>