<div dir="auto">Sorry, the parsing is tied to fromInteger. So i see what you mean about the poor errors not being as comparable. Henning and another brought up a good point, that either users ought to be warned or it would go in its own module ala Text.Show.Function.</div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 11, 2018, 5:30 PM Daniel Cartwright <<a href="mailto:chessai1996@gmail.com">chessai1996@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">I'm not quite sure the comparison is unjust - i was referring to +,-,* giving strange error messages, not necessarily fromInteger. Recall that the instance is Monoid b => Monoid (a -> b).<div dir="auto"><br></div><div dir="auto">An example is a user might mistakenly type `mempty "text"`, which is just `const mempty`, though this might not be what they mean (GHC 8.6 will give the hole in `f :: Text -> Text; f x = _ x;` a suggestion of `mempty`, which might certainly be confusing to a beginner). Similarly `2 4` might parse 2 as being applied to 4, if (a -> b) had a Num instance (correct me if i'm wrong in saying thats how such a string might be parsed).</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 11, 2018, 5:10 PM Oleg Grenrus <<a href="mailto:oleg.grenrus@iki.fi" rel="noreferrer noreferrer" target="_blank">oleg.grenrus@iki.fi</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div style="direction:inherit">Monoid doesn't have fromInteger -like function. For example, we don't have FromString b => FromString (a -> b) instance.</div><div style="direction:inherit"><br></div><div style="direction:inherit">Unfortunately fromInteger is part of Num, so comparison with Monoid is unjust.</div><div style="direction:inherit"><br></div>Sent from my iPhone</div><div><br>On 11 Nov 2018, at 23.44, Daniel Cartwright <<a href="mailto:chessai1996@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">chessai1996@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="auto">ANum seems to be just Data.Monoid.Ap. <div dir="auto">Also, I can see not wanting to worsen the error messages, though it is worth pointing out that we already have a Monoid instance with the same semantics, and a similar potential for confusing error messages.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 11, 2018, 1:36 AM Dan Burton <<a href="mailto:danburton.email@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">danburton.email@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">-1, per the very confusing errors that would ensue.<br><br>If this behavior is desired, you can use a newtype wrapper. As it happens, this fits the pattern of <a href="http://hackage.haskell.org/package/ANum" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">ANum</a>. (Any Applicative can be made an instance of Num in this way.)<div><br><div><div><div dir="ltr" class="m_-4072348511431030900m_2351471011377907104m_-7605251411511685802m_6957556419282998197gmail_signature" data-smartmail="gmail_signature">-- Dan Burton</div></div><br><input name="virtru-metadata" type="hidden" value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"expires":false,"isManaged":false},"attachments":{},"compose-id":"5","compose-window":{"secure":false}}"></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 11, 2018 at 12:28 AM Tom Murphy <<a href="mailto:amindfv@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">amindfv@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/11/18, Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">lemming@henning-thielemann.de</a>> wrote:<br>
><br>
> On Sun, 11 Nov 2018, Henning Thielemann wrote:<br>
><br>
>> On Sat, 10 Nov 2018, Daniel Cartwright wrote:<br>
>><br>
>>> relevant reddit comment<br>
>>> thread:<a href="https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so</a><br>
>>> urce=reddit-android<br>
>><br>
>> <a href="https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632</a><br>
>><br>
>> In short: It would make 2(x+y) no longer a type error but equivalent to 2.<br>
>> We<br>
>> would lose a lot of type safety for little syntactic gain.<br>
><br>
> Btw. before adding more Wat instances please implement the GHC warning<br>
> about such instances:<br>
>     <a href="https://ghc.haskell.org/trac/ghc/ticket/11796" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/11796</a><br>
<br>
This is my feeling as well.<br>
<br>
Tom<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Libraries mailing list</span><br><span><a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer noreferrer" target="_blank">Libraries@haskell.org</a></span><br><span><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a></span><br></div></blockquote></div></blockquote></div>
</blockquote></div>