Proposal: Num instance for (a -> b)

[Daniel Cartwright]

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 at 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 at 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 at 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 at 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 at 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
>>>> <http://hackage.haskell.org/package/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 at gmail.com> wrote:
>>>>
>>>>> On 11/11/18, Henning Thielemann <lemming at 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 at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181111/0c4289f9/attachment.html>