Is this a GHC bug? Problem inferring type

older
type inference: how ghc chooses...

Peter Hall

8 Jun 2013 8 Jun '13

9:02 a.m.

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

Attachments:

attachment.html (text/html — 832 bytes)

Show replies by date

Brandon Allbery

8 Jun 8 Jun

9:35 a.m.

On Sat, Jun 8, 2013 at 9:02 AM, Peter Hall 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@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Peter Hall

9:39 a.m.

Ah, thanks for the explanation. I hadn't heard of ExtendedDefaultRules before. Peter On 8 June 2013 14:35, Brandon Allbery wrote:

...

On Sat, Jun 8, 2013 at 9:02 AM, Peter Hall 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@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Michael Peternell

2:54 p.m.

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 :

...

On Sat, Jun 8, 2013 at 9:02 AM, Peter Hall 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@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Brandon Allbery

3:33 p.m.

On Sat, Jun 8, 2013 at 2:54 PM, Michael Peternell 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@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Peter Hall

4:11 p.m.

...

...
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

Graham Gill

4:15 p.m.

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

Peter Hall

4:26 p.m.

Oops :) On 8 June 2013 21:15, Graham Gill 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

Brandon Allbery

6:49 p.m.

On Sat, Jun 8, 2013 at 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...

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@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Peter Hall

8:16 p.m.

...

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

Brandon Allbery

9 Jun 9 Jun

9:45 a.m.

On Sat, Jun 8, 2013 at 8:16 PM, Peter Hall 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@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

4363

Age (days ago)

4364

Last active (days ago)

List overview

Download

10 comments

4 participants

participants (4)

Brandon Allbery
Graham Gill
Michael Peternell
Peter Hall