Proposal: Num instance for (a -> b)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: Num instance for (a -> b)

chessai .
relevant reddit comment thread: https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_source=reddit-android

instance Num b => Num (a -> b) where
  f + g = \x -> f x + g x
  f * g = \x -> f x * g x
  f - g = \x -> f x - g x
  negate f = \x -> negate (f x)
  abs f = \x -> abs (f x)
  signum f = \x -> signum (f x)
  fromInteger i = \x -> fromInteger (f x)

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

Henning Thielemann

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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

Dannyu NDos
In reply to this post by chessai .
I'm +1 on this, since it is conventional to write addition (and others) over function as such in most math textbooks.

2018년 11월 11일 (일) 13:48에 Daniel Cartwright <[hidden email]>님이 작성:
relevant reddit comment thread: https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_source=reddit-android

instance Num b => Num (a -> b) where
  f + g = \x -> f x + g x
  f * g = \x -> f x * g x
  f - g = \x -> f x - g x
  negate f = \x -> negate (f x)
  abs f = \x -> abs (f x)
  signum f = \x -> signum (f x)
  fromInteger i = \x -> fromInteger (f x)
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

Henning Thielemann
In reply to this post by Henning Thielemann

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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

Dannyu NDos
I suggest adding this as an orphan instance (Like Show (a -> b)) in a seperate module (say, Numeric.Function).

2018년 11월 11일 (일) 14:01에 Henning Thielemann <[hidden email]>님이 작성:

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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

Henning Thielemann

On Sun, 11 Nov 2018, Dannyu NDos wrote:

> I suggest adding this as an orphan instance (Like Show (a -> b)) in a seperate module (say, Numeric.Function).

https://hackage.haskell.org/package/NumInstances

It would not save much, because in a reasonably big project you will
somewhen import a package that transitively depends on the module. E.g.
'diagrams-canvas' depends on NumInstances.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

amindfv
In reply to this post by Henning Thielemann
On 11/11/18, Henning Thielemann <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

Dan Burton
-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 <[hidden email]> wrote:
On 11/11/18, Henning Thielemann <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

chessai .
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 <[hidden email] 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 <[hidden email]> wrote:
On 11/11/18, Henning Thielemann <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

Oleg Grenrus
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 <[hidden email]> 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 <[hidden email] 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 <[hidden email]> wrote:
On 11/11/18, Henning Thielemann <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

chessai .
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 <[hidden email] 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 <[hidden email]> 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 <[hidden email] 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 <[hidden email]> wrote:
On 11/11/18, Henning Thielemann <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

chessai .
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 <[hidden email] 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 <[hidden email] 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 <[hidden email]> 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 <[hidden email] 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 <[hidden email]> wrote:
On 11/11/18, Henning Thielemann <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

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



On Sun, Nov 11, 2018, 5:42 PM Daniel Cartwright <[hidden email] 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 <[hidden email] 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 <[hidden email] 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 <[hidden email]> 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 <[hidden email] 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 <[hidden email]> wrote:
On 11/11/18, Henning Thielemann <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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.



On Sun, Nov 11, 2018, 5:42 PM Daniel Cartwright <[hidden email] 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 <[hidden email] 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 <[hidden email] 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 <[hidden email]> 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 <[hidden email] 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 <[hidden email]> wrote:
On 11/11/18, Henning Thielemann <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

Haskell - Libraries mailing list
In reply to this post by Oleg Grenrus
Oleg Grenrus wrote:
> Monoid doesn't have fromInteger -like function. For example, we don't have FromString b => FromString (a -> b) instance.

Monoid does have `mempty` though, with the unfortunate property that

  mempty [1,2] /= mempty `mappend` [1,2]

But I'm less worried about this than in the case of Num; I occasionally
copy formulas from a CAS into Haskell code and then add the missing *
operations manually; I estimate that about half of the time I miss one
instance and am rescued by the type checker. So to me, `2 (x + y)` no
longer being a type error would have practical implications.

-1 on the proposal from me.

Cheers,

Bertram
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

Jon Fairbairn
In reply to this post by chessai .
Daniel Cartwright <[hidden email]> writes:

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

The existence of a previous bad decision doesn’t seem to me to
be a good reason to make another one.

--
Jón Fairbairn                                 [hidden email]
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2014-04-05)

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

chessai .
I'm not sure I would label it a bad decision, but the concerns here make sense.

On Mon, Nov 12, 2018, 5:16 AM Jon Fairbairn <[hidden email] wrote:
Daniel Cartwright <[hidden email]> writes:

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

The existence of a previous bad decision doesn’t seem to me to
be a good reason to make another one.

--
Jón Fairbairn                                 [hidden email]
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2014-04-05)

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

AntC
In reply to this post by chessai .
relevant reddit comment thread: ...
Are you people completely nuts? Haven't you wreaked enough havoc with the Foldable Traversable Piffle?

Why ref pointy-headed discussion on reddit when you could also ref far more frequent complaints:

"I think there must be something really wrong with the language design here. I don't know exactly what it is, but I think someone must have made the wrong tradeoff at some point."

(It's by no means only that author complaining; it's just that was easiest to grab.)

No, EKmett, including `length` in `Foldable` with a `((,) a)` instance is a lot more serious than "somewhat unfortunate".

> At what point is it better to put "weird" stuff into its own libraries (or newtypes) and keep base clean?

Always the standard Prelude should be clean of "weird" stuff. So that beginners don't have to go round the houses to exclude the standard and get a sensible Prelude. A beginner has more than enough to cope with without piling the import mechanism on them.

Whereas it's no burden on the pointy-heads to import WeirdPrelude.

If the CLC process were to do anything useful, I'd expect yous to be organising that. And then I could leave yew lot to turn your Haskell into Perl, where any composition of symbols can acquire some meaning.

As it is, the only reason I monitor the Libraries list is to complain about proposals for nuttiness.

AntC



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Num instance for (a -> b)

Henning Thielemann

On Sat, 17 Nov 2018, Anthony Clayden wrote:

> > relevant reddit comment thread: ...
>
> Are you people completely nuts? Haven't you wreaked enough havoc with the Foldable Traversable Piffle?

I am still using at most GHC-7.8.4 as main compiler because of broken type
safety starting from GHC-7.10. Breaking type safety for everyone was
achieved quickly, but restoring at least a bit of it for the ones who care
will certainly not happen for years (presumedly not before more Wats are
implemented):
    https://ghc.haskell.org/trac/ghc/ticket/11796

However, I cannot see how this relates to the Foldable desaster or to the
Num (a -> b) issue:

> Why ref pointy-headed discussion on reddit when you could also ref far more frequent complaints:
> https://blog.plover.com/prog/haskell/type-errors.html
> "I think there must be something really wrong with the language design here. I don't know exactly what it is, but
>  I think someone must have made the wrong tradeoff at some point."

Since he already defined 'adj' as top-level function, I'd suggest he gives
it a monomorphic type signature and all type ambiguities are gone.
Top-level type signatures are good style anyway.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries