Proposal: Num instance for (a -> b)

[Dan Burton]

>
> The overloading of integer literals to functions does seem disruptive.


Most, if not all, of my objection has to do with the concern that integer
literals (and floating point literals, if functions also got a comparable
Floating instance) could be accidentally used as functions. Everything else
about these potential instances seems benign.

-- Dan Burton


On Sun, Nov 11, 2018 at 5:46 PM Daniel Cartwright <chessai1996 at gmail.com>
wrote:

> 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/84f54ebc/attachment.html>