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> |
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> |
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 > An HTML attachment was scrubbed... URL: <http://www.haskell.org/pipermail/beginners/attachments/20130608/e4928352/attachment.htm> |
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 |
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> |
>
When are we due a new spec? 1998 was quite a while ago...
>> 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.) > > Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.haskell.org/pipermail/beginners/attachments/20130608/3c240a50/attachment.htm> |
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> |
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> > An HTML attachment was scrubbed... URL: <http://www.haskell.org/pipermail/beginners/attachments/20130608/49aec637/attachment.htm> |
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> |
>
> > 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> |
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> |
Free forum by Nabble | Edit this page |