Andreas Abel | 15 Jun 09:59 2012
Picon

Data.Tuple impoverished

Hi,

the module Data.Tuple offers a sad collection of 5 functions.  Many 
standard functions are missing.  For instance, I'd expect all the 
functions of

   Data.Tuple.HT  (package utility-th)

to be part of Data.Tuple, which are

   mapPair :: (a -> c, b -> d) -> (a, b) -> (c, d)
   mapFst :: (a -> c) -> (a, b) -> (c, b)
   mapSnd :: (b -> c) -> (a, b) -> (a, c)
   -- swap :: (a, b) -> (b, a)  -- swap is present in Data.Tuple
   forcePair :: (a, b) -> (a, b)
   fst3 :: (a, b, c) -> a
   snd3 :: (a, b, c) -> b
   thd3 :: (a, b, c) -> c
   curry3 :: ((a, b, c) -> d) -> a -> b -> c -> d
   uncurry3 :: (a -> b -> c -> d) -> (a, b, c) -> d

Is there a good reason why they aren't?

Cheers,
Andreas

P.S.: I have reimplemented all these functions for myself, because I use 
them, but I am puzzled why they are not in the standard library.

--

-- 
(Continue reading)

Ivan Lazar Miljenovic | 15 Jun 10:02 2012
Picon

Re: Data.Tuple impoverished

On 15 June 2012 17:59, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:
> Hi,
>
> the module Data.Tuple offers a sad collection of 5 functions.  Many standard
> functions are missing.  For instance, I'd expect all the functions of
>
>  Data.Tuple.HT  (package utility-th)
>
> to be part of Data.Tuple, which are
>
>  mapPair :: (a -> c, b -> d) -> (a, b) -> (c, d)
>  mapFst :: (a -> c) -> (a, b) -> (c, b)
>  mapSnd :: (b -> c) -> (a, b) -> (a, c)

I believe these are covered by Control.Arrow...

>  -- swap :: (a, b) -> (b, a)  -- swap is present in Data.Tuple
>  forcePair :: (a, b) -> (a, b)
>  fst3 :: (a, b, c) -> a
>  snd3 :: (a, b, c) -> b
>  thd3 :: (a, b, c) -> c
>  curry3 :: ((a, b, c) -> d) -> a -> b -> c -> d
>  uncurry3 :: (a -> b -> c -> d) -> (a, b, c) -> d

I wouldn't mind seeing these though.

>
> Is there a good reason why they aren't?
>
> Cheers,
(Continue reading)

Herbert Valerio Riedel | 15 Jun 12:25 2012
Picon

Re: Data.Tuple impoverished

Ivan Lazar Miljenovic <ivan.miljenovic <at> gmail.com> writes:

>>  mapPair :: (a -> c, b -> d) -> (a, b) -> (c, d)
>>  mapFst :: (a -> c) -> (a, b) -> (c, b)
>>  mapSnd :: (b -> c) -> (a, b) -> (a, c)
>
> I believe these are covered by Control.Arrow...

I'm not sure those are really equivalent, as the ones from
"Data.Tuple.HT" use lazy pattern matching, e.g.:

mapPair ~(f,g) ~(x,y) = (f x, g y)

mapFst f ~(a,b) = (f a, b)

mapSnd f ~(a,b) = (a, f b)

--

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ross Paterson | 15 Jun 13:28 2012
Picon

Re: Data.Tuple impoverished

On Fri, Jun 15, 2012 at 11:25:56AM +0100, Herbert Valerio Riedel wrote:
> Ivan Lazar Miljenovic <ivan.miljenovic <at> gmail.com> writes:
> 
> >>  mapPair :: (a -> c, b -> d) -> (a, b) -> (c, d)
> >>  mapFst :: (a -> c) -> (a, b) -> (c, b)
> >>  mapSnd :: (b -> c) -> (a, b) -> (a, c)
> >
> > I believe these are covered by Control.Arrow...
> 
> I'm not sure those are really equivalent, as the ones from
> "Data.Tuple.HT" use lazy pattern matching, e.g.:
> 
> mapPair ~(f,g) ~(x,y) = (f x, g y)
> 
> mapFst f ~(a,b) = (f a, b)
> 
> mapSnd f ~(a,b) = (a, f b)

From Control.Arrow:

instance Arrow (->) where
    arr f = f
    first f = f *** id
    second f = id *** f
    (***) f g ~(x,y) = (f x, g y)
Henning Thielemann | 15 Jun 14:48 2012
Picon

Re: Data.Tuple impoverished


On Fri, 15 Jun 2012, Ivan Lazar Miljenovic wrote:

> On 15 June 2012 17:59, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:
>> Hi,
>>
>> the module Data.Tuple offers a sad collection of 5 functions.  Many standard
>> functions are missing.  For instance, I'd expect all the functions of
>>
>>  Data.Tuple.HT  (package utility-th)
>>
>> to be part of Data.Tuple, which are
>>
>>  mapPair :: (a -> c, b -> d) -> (a, b) -> (c, d)
>>  mapFst :: (a -> c) -> (a, b) -> (c, b)
>>  mapSnd :: (b -> c) -> (a, b) -> (a, c)
>
> I believe these are covered by Control.Arrow...

Yes, they are covered by 'first', 'second' and '***'. But I decided to 
implement them in Data.Tuple.HT because I think that the use of the pair 
type in 'first' and friends is not the focus of the arrow functions. It 
would be easy for me to add mapFst3, mapSnd3.

>>  -- swap :: (a, b) -> (b, a)  -- swap is present in Data.Tuple

I have also added such functions in order to allow people to write code 
that works for many different GHC and 'base' versions.

>> P.S.: I have reimplemented all these functions for myself, because I use
(Continue reading)

Twan van Laarhoven | 15 Jun 15:04 2012
Picon

Re: Data.Tuple impoverished

On 15/06/12 09:59, Andreas Abel wrote:
> Hi,
>
> the module Data.Tuple offers a sad collection of 5 functions.  Many standard
> functions are missing.  For instance, I'd expect all the functions of
>
>    Data.Tuple.HT  (package utility-th)
>
> to be part of Data.Tuple, ...
> Is there a good reason why they aren't?

I am strongly in favor of adding these functions to Data.Tuple, there is no good 
reason for them not to be there. I would also support in addition to mapTriple, 
mapFst3, etc.

Twan
Henning Thielemann | 15 Jun 15:11 2012
Picon

Re: Data.Tuple impoverished


On Fri, 15 Jun 2012, Twan van Laarhoven wrote:

> I am strongly in favor of adding these functions to Data.Tuple, there is no 
> good reason for them not to be there. I would also support in addition to 
> mapTriple, mapFst3, etc.

I can just add them to Data.Tuple.HT. Then you can use them immediately 
and even more, people do not need to upgrade GHC in order to use packages 
that call the new functions.
Stephen Tetley | 15 Jun 19:03 2012
Picon

Re: Data.Tuple impoverished

> mapPair :: (a -> c, b -> d) -> (a, b) -> (c, d)
> mapFst :: (a -> c) -> (a, b) -> (c, b)
> mapSnd :: (b -> c) -> (a, b) -> (a, c)

These three could be replaced by a more general (and often defined)
bifunctor class

class Bifunctor f where
  bimap  :: (a -> c) -> (b -> d) -> f a b -> f c d
  mapFst :: (a -> c) -> f a b -> f c b	-- or mapL
  mapSnd :: (b -> d) -> f a b -> f a d  -- or mapR

This class also has a useful instance for Either in Base.

> fst3 :: (a, b, c) -> a
> snd3 :: (a, b, c) -> b
> thd3 :: (a, b, c) -> c

This naming scheme for extractors from pairs (then triples) doesn't
really extend to 4 tuples or higher, maybe a rethink is useful before
a commit to the Base libraries. Of the top of my head, fst and snd are
the only bits of "vowel dropping" as a naming scheme I can think of in
Base, maybe it is not a tradition to continue, though SML has a few
more like hd and tl.

Gmane