<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 6:55 PM, William Yager <span dir="ltr"><<a href="mailto:will.yager@gmail.com" target="_blank">will.yager@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"C => T" means (or is equivalent to) "A function which takes an implicit parameter C and returns a T". There's no particular reason this can't show up on the RHS of a "->" arrow.</blockquote></div><br>The Report requires that all constraints be in a tuple before the rest of a signature. ghc relaxes this since it implements not Haskell 2010, but System FC. But yes, this is why it's syntactically correct once you enable any extension that liberalizes type signature parsing. (Even without, ghc permits constraint => constraint ... => type for reasons that iirc are hard to "fix" and are not really considered bugs, just not Haskell 2010 syntax; but ghc's Haskell 2010 support broke when Num lost Eq and Show superclasses, and broke further when Monad gained Applicative prerequisite/"superclass", so nobody's much worried about the Report violation.)<br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh                               sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>                                  <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad        <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div></div>