It would be nice if the Semiring/Ring[1] parts of Num were pulled into its own class. The overloading of integer literals to functions does seem disruptive.

[1]: http://hackage.haskell.org/package/semirings-0.2.1.1/docs/Data-Semiring.html

On Sun, Nov 11, 2018, 5:42 PM Daniel Cartwright <chessai1996@gmail.com wrote:

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.

On Sun, Nov 11, 2018, 5:30 PM Daniel Cartwright <chessai1996@gmail.com wrote:

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).

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).

On Sun, Nov 11, 2018, 5:10 PM Oleg Grenrus <oleg.grenrus@iki.fi wrote:

Monoid doesn't have fromInteger -like function. For example, we don't have FromString b => FromString (a -> b) instance.

Unfortunately fromInteger is part of Num, so comparison with Monoid is unjust.

Sent from my iPhone

On 11 Nov 2018, at 23.44, Daniel Cartwright <chessai1996@gmail.com> wrote:

ANum seems to be just Data.Monoid.Ap. 

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.

On Sun, Nov 11, 2018, 1:36 AM Dan Burton <danburton.email@gmail.com wrote:

-1, per the very confusing errors that would ensue.

If this behavior is desired, you can use a newtype wrapper. As it happens, this fits the pattern of ANum. (Any Applicative can be made an instance of Num in this way.)

-- Dan Burton

On Sun, Nov 11, 2018 at 12:28 AM Tom Murphy <amindfv@gmail.com> wrote:

On 11/11/18, Henning Thielemann <lemming@henning-thielemann.de> wrote:
>
> On Sun, 11 Nov 2018, Henning Thielemann wrote:
>
>> On Sat, 10 Nov 2018, Daniel Cartwright wrote:
>>
>>> relevant reddit comment
>>> thread:https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so
>>> urce=reddit-android
>>
>> https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632
>>
>> In short: It would make 2(x+y) no longer a type error but equivalent to 2.
>> We
>> would lose a lot of type safety for little syntactic gain.
>
> Btw. before adding more Wat instances please implement the GHC warning
> about such instances:
>     https://ghc.haskell.org/trac/ghc/ticket/11796

This is my feeling as well.

Tom
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries