<div dir="ltr">Just to add my own +1, having this when working with streaming libraries (I've needed it less with lens, oddly) would be a tremendous help for people learning them I think. I think I've run into the same thing as Kostiantyn in the past.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 18, 2015 at 9:42 PM, Ömer Sinan Ağacan <span dir="ltr"><<a href="mailto:omeragacan@gmail.com" target="_blank">omeragacan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's good to see that I'm not the only one who wants this. I'm doing<br>
some GHC hacking nowadays and I'll give it a try.<br>
<div class="HOEnZb"><div class="h5"><br>
2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov <<a href="mailto:k-bx@k-bx.com">k-bx@k-bx.com</a>>:<br>
> I wanted to add that synonym expansion would be especially helpful in<br>
> error-messages like:<br>
><br>
> Expected type: <non-expanded, small type, like "Producer a m ()"><br>
> Actual type: <your type, like "Proxy a a' b b' m v"><br>
><br>
> I would be glad if we could have an expansions enabling flag in GHC, and<br>
> could consider turning it on by default if it will look good for that.<br>
><br>
> 16 черв. 2015 22:44 "Richard Eisenberg" <<a href="mailto:eir@cis.upenn.edu">eir@cis.upenn.edu</a>> пише:<br>
><br>
>> GHC tries hard to preserve type synonyms where possible, but of course, it<br>
>> can't preserve all of them. The general rule it tries to follow is: preserve<br>
>> vanilla type synonyms; expand type families. This is true both in expected<br>
>> types and actual types.<br>
>> If you have a case where you believe that GHC could preserve a type<br>
>> synonym in an expected type, submit a bug report. (Note that constraint<br>
>> synonyms are particularly hard to preserve!)<br>
>><br>
>> It would be very easy to report both the synonym-preserving form and the<br>
>> expanded form in an error report, at the cost of making error reports even<br>
>> more verbose. You're welcome to submit a feature request, and this would<br>
>> likely make a good first patch to GHC if you want to get your hands dirty.<br>
>> I'd personally prefer the feature to be protected behind a flag (to avoid<br>
>> seeing that `String` expands to `[Char]` everywhere, for example), but<br>
>> others may feel differently here.<br>
>><br>
>> Richard<br>
>><br>
>> On Jun 16, 2015, at 11:20 AM, Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com">omeragacan@gmail.com</a>><br>
>> wrote:<br>
>><br>
>> > Hi all,<br>
>> ><br>
>> > While working with complex types with lots of arguments etc. errors are<br>
>> > becoming annoying very fast. For example, GHC prints errors in this way:<br>
>> ><br>
>> >    Expected type: <type without any synonyms><br>
>> >      Actual type: <type with synonyms><br>
>> ><br>
>> > Now I have to expand that synonym in my head to understand the error.<br>
>> ><br>
>> > I was wondering if implementing something like this is possible:<br>
>> ><br>
>> > In type error messages, GHC also prints types that are cleaned from type<br>
>> > synonyms. Maybe something like this:<br>
>> ><br>
>> >         Expected type: <type1><br>
>> >    (without synonyms): <type1, synonyms are expanded><br>
>> >           Actual type: <type2><br>
>> >    (without synonyms): <type2, synonyms are expanded><br>
>> ><br>
>> > If this is not always desirable for some reason, we can hide this<br>
>> > behavior<br>
>> > behind a flag.<br>
>> ><br>
>> > What do GHC devs think about this? Is this, in theory, possible to do?<br>
>> > How hard<br>
>> > would it be to implement this?<br>
>> ><br>
>> > Thanks.<br>
>> > _______________________________________________<br>
>> > ghc-devs mailing list<br>
>> > <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
>> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
>><br>
>> _______________________________________________<br>
>> ghc-devs mailing list<br>
>> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Chris Allen<br><div><span style="font-size:12.8000001907349px">Currently working on </span><a href="http://haskellbook.com" target="_blank">http://haskellbook.com</a></div></div></div></div></div></div>
</div>