On 10/19/12 7:29 AM, Simon Marlow wrote:

On 18/10/2012 11:07, Henning Thielemann wrote:

...

On Thu, 18 Oct 2012, Twan van Laarhoven wrote:

...

One piece of utility code that I find myself writing over and over again is the pointwise Num instance for tuples, i.e.

For my taste, writing

2 :: (Int, Integer)

abs (x,y)

should yield a compiler error and the compiler should not try to interpret it in some way. For the cases where you need these instances I suggest you use custom data types.

Agreed, -1 from me.

Agreed, another -1. -- Live well, ~wren

-1 for the same reason, there is no canonical interpretation of 1 as a tuple (could be (1,1), (0,1), (1,0) or s.th. else, no obvious choice...) On 18.10.2012 12:25, Simon Hengel wrote:

On Thu, Oct 18, 2012 at 11:58:17AM +0200, Twan van Laarhoven wrote:

...

Dear list,

One piece of utility code that I find myself writing over and over again is the pointwise Num instance for tuples, i.e.

instance (Num a, Num b) => Num (a,b) where fromInteger x = (fromInteger x, fromInteger x) (a,b) + (a',b') = (a + a', b + b') (a,b) - (a',b') = (a - a', b - b') (a,b) * (a',b') = (a * a', b * b') negate (a,b) = (negate a, negate b) abs (a,b) = (abs a, abs b) signum (a,b) = (signum a, signum b)

I therefore propose that this instance be added to the base library. If we do that, the equivalent instances for (,,) (,,,) etc. should perhaps also be added, as well as instances for other numeric classes such as Fractional and Floating.

While I see *some* value in being able to perform addition, etc. on tuples, I still think that e.g. something like

fst (2 :: Point)

can easily lead to code obfuscation.

For that reason, -1.

Cheers, Simon

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

On Thu, Oct 18, 2012 at 7:34 AM, Edward Kmett wrote:

Unlike the rest of the comments so far, I am

+1

to this proposal.

It has the only reasonable semantics.

There are at least two reasonable choices. The first is this. The second is given by the fact that for any Num a and Applicative f, we can write Num (f a) by lifting all the operations. I suppose the one proposed here might be more commonly used. -- Dan

On 19 October 2012 04:57, Henning Thielemann wrote:

On Thu, 18 Oct 2012, Brent Yorgey wrote:

...

I am +1 for this proposal, but only as long as these instances are not exported by the Prelude. They are useful when you know you want them but will confuse newbies -- based on evidence from #haskell, where lambdabot has such instances in scope.

Please no orphan instances - I think a pair type that supports arithmetics deserves a custom type.

Agreed. Another -1 on the proposal from me. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

Our V2 doesn't *quite* match, since V2 requires the two fields to have the same type, but I agree. =) On Thu, Oct 18, 2012 at 2:36 PM, Anthony Cowley wrote:

On Thu, Oct 18, 2012 at 4:47 PM, Ivan Lazar Miljenovic wrote:

...

On 19 October 2012 04:57, Henning Thielemann wrote:

...

On Thu, 18 Oct 2012, Brent Yorgey wrote:

...

I am +1 for this proposal, but only as long as these instances are not exported by the Prelude. They are useful when you know you want them but will confuse newbies -- based on evidence from #haskell, where lambdabot has such instances in scope.

Please no orphan instances - I think a pair type that supports

arithmetics

...

deserves a custom type.

Agreed. Another -1 on the proposal from me.

I am also with Henning, and a -1 for the proposal. If it's too confusing to export by default, then the instance belongs to a less general type. There are appropriate types that have the desired behavior all over hackage. I am currently partial to V2 from the linear package.

Anthony

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries