<div dir="ltr">And in case it proves intractable to provide concise, useful error messages, perhaps having entries at <a href="https://errors.haskell.org">https://errors.haskell.org</a> (with examples!) would also be helpful.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 15 May 2023 at 18:07, Olaf Klinke <<a href="mailto:olf@aatal-apotheke.de">olf@aatal-apotheke.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2023-05-12 at 17:13 -0400, Brandon Allbery wrote:<br>
> My first suspicion would be simplified subsumption. Try eta-expanding them.<br>
> <br>
<br>
Indeed, the eta-expanded versions do compile with GHC >= 9.<br>
Now I remember that I've fallen into a similar trap before [1] (and<br>
Brandon offered the right hint back then, too. Thanks, Brandon!)  <br>
So let me re-cap: <br>
(1) Haskell is not a category: there are types a, b, c <br>
    and morphisms f :: a -> b, g :: b -> c<br>
    such that g.f is not a morphism.<br>
(2) Haskell is not a lambda calculus [2]: There are terms f such that <br>
    \x -> f x <br>
    belongs to the calculus but f does not.<br>
<br>
Personally, I would already call the situation improved when the<br>
compiler instead of Brandon could tell me the fix. From the discussion<br>
[3]:<br>
<br>
> The most interesting thing I've learned from the lengthy threads,<br>
> along with deficiencies in the testing process for ecosystem<br>
> breakage, is how much absolute confusion there is over how rank-n-<br>
> types work, and the limitations and complexities of algorithms<br>
> pertaining to them. Now that they are in widespread use and on by<br>
> default in ghc, it seems like an important case where user education<br>
> is warranted.<br>
<br>
I'd love to be educated. And I'd be very pleased if helpful compiler<br>
error messages were the first entry point for that, so that I can spare<br>
the patient and helpful Haskell Cafe members some time. <br>
<br>
Olaf<br>
<br>
[1] <a href="https://mail.haskell.org/pipermail/haskell-cafe/2023-February/135903.html" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/haskell-cafe/2023-February/135903.html</a><br>
[2] <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst#costs-and-drawbacks" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst#costs-and-drawbacks</a><br>
[3] <a href="https://github.com/ghc-proposals/ghc-proposals/pull/287" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/287</a><br>
<br>
that apparently I have not managed to form an in<br>
<br>
> On Fri, May 12, 2023 at 5:10 PM Olaf Klinke <<a href="mailto:olf@aatal-apotheke.de" target="_blank">olf@aatal-apotheke.de</a>> wrote:<br>
> > <br>
> > Dear Cafe,<br>
> > <br>
> > I'm an infrequent lens user so please forgive me if the below problem<br>
> > has a trivial solution.<br>
> > <br>
> > For a long time the documentation of Control.Lens.Zoom has been<br>
> > claiming that 'zoom' and 'magnify' can be specialized to the following<br>
> > types.<br>
> > <br>
> > {-# LANGUAGE RankNTypes #-}<br>
> > -- Type error with GHC 9.0.2 or 9.2.7, okay with GHC 8.8.4<br>
> > import Control.Lens.Zoom (zoom,magnify)<br>
> > import Control.Lens.Type (Lens')<br>
> > import Control.Monad.RWS (RWS)<br>
> > zoomRWS ::    Monoid w => Lens' s s' -> RWS r w s' a -> RWS r w s a<br>
> > zoomRWS = zoom<br>
> > magnifyRWS :: Monoid w => Lens' r r' -> RWS r' w s a -> RWS r w s a<br>
> > magnifyRWS = magnify<br>
> > <br>
> > Indeed GHC 8.8.4 compiles this happily (on lens-4.18.1), but 9.0.2 (on<br>
> > lens-5.0.1) throws nearly undecipherable errors, claiming that Lens'<br>
> > can not be matched with some more specialized type involving Magnified<br>
> > and LensLike.<br>
> > The source of Control.Lens.Zoom does not differ substantially between<br>
> > 4.18.1 and 5.0.1 so my guess is it is a type checker issue. Can anyone<br>
> > explain? On which bug tracker should I raise this issue, if it is<br>
> > indeed a valid one?<br>
> > (I pulled the above versions from stackage lts-16.31, -19.5 and -20.20,<br>
> > respectively and compiled with stack.)<br>
> > <br>
> > Thanks<br>
> > Olaf<br>
> > <br>
> > _______________________________________________<br>
> > Haskell-Cafe mailing list<br>
> > To (un)subscribe, modify options or view archives go to:<br>
> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> > Only members subscribed via the mailman list are allowed to post.<br>
> <br>
> <br>
> <br>
<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>