Discussion:
Adding dup to Data.Tuple?
Add Reply
Ivan Perez
2018-10-27 22:03:13 UTC
Reply
Permalink
Dear all,

The function \x -> (x,x) is very convenient when working with arrows.

Would it be appropriate to add it to Data.Tuple?

Cheers,

Ivan
Vanessa McHale
2018-10-28 04:08:48 UTC
Reply
Permalink
Out of curiosity, do you have any examples?

Cheers
Post by Ivan Perez
Dear all,
The function \x -> (x,x) is very convenient when working with arrows.
Would it be appropriate to add it to Data.Tuple?
Cheers,
Ivan
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
David Feuer
2018-10-28 04:47:38 UTC
Reply
Permalink
I'm not opposed. Should this be called dup or diagonal? What about larger
tuples?

Side note:
\x -> (x,x) = join (,)
Post by Ivan Perez
Dear all,
The function \x -> (x,x) is very convenient when working with arrows.
Would it be appropriate to add it to Data.Tuple?
Cheers,
Ivan
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Dan Burton
2018-10-28 06:03:01 UTC
Reply
Permalink
There is precedent in the arrow literature for calling this function "dup".
For example, on page 55 of this paper:
http://homepages.inf.ed.ac.uk/wadler/papers/arrows-jfp/arrows-jfp.pdf

-- Dan Burton
Post by David Feuer
I'm not opposed. Should this be called dup or diagonal? What about larger
tuples?
\x -> (x,x) = join (,)
Post by Ivan Perez
Dear all,
The function \x -> (x,x) is very convenient when working with arrows.
Would it be appropriate to add it to Data.Tuple?
Cheers,
Ivan
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Dannyu NDos
2018-10-28 07:51:58 UTC
Reply
Permalink
If this is for convenience for arrows, isn't it better implemented as?:

dup :: Arrow a => a b (b,b)
dup = id &&& id
Post by Dan Burton
There is precedent in the arrow literature for calling this function
http://homepages.inf.ed.ac.uk/wadler/papers/arrows-jfp/arrows-jfp.pdf
-- Dan Burton
Post by David Feuer
I'm not opposed. Should this be called dup or diagonal? What about larger
tuples?
\x -> (x,x) = join (,)
Post by Ivan Perez
Dear all,
The function \x -> (x,x) is very convenient when working with arrows.
Would it be appropriate to add it to Data.Tuple?
Cheers,
Ivan
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Ivan Perez
2018-10-28 11:52:24 UTC
Reply
Permalink
Post by Dannyu NDos
dup :: Arrow a => a b (b,b)
dup = id &&& id
Hi

Performance aside, I'd say your suggestion is better than using a pure
function. It's clearer about what it does, and it works for functions as
well (since they are arrows).

Ivan
Vanessa McHale
2018-10-28 13:48:42 UTC
Reply
Permalink
According to GHCi,

λ:> import Control.Arrow
λ:> :t (id &&& id) (id &&& id) :: b -> (b, b)

That is, this implementation has type a -> (a, a) as well.
Post by Ivan Perez
Post by Dannyu NDos
dup :: Arrow a => a b (b,b)
dup = id &&& id
Hi
Performance aside, I'd say your suggestion is better than using a pure
function. It's clearer about what it does, and it works for functions
as well (since they are arrows).
Ivan
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Ivan Perez
2018-10-28 16:07:30 UTC
Reply
Permalink
Post by Vanessa McHale
According to GHCi,
λ:> import Control.Arrow
λ:> :t (id &&& id)
(id &&& id) :: b -> (b, b)
That is, this implementation has type a -> (a, a) as well.
Yes, yes, that's what I meant by "it works for functions as well (since
they are arrows)"

Ivan
Edward Kmett
2018-10-28 22:10:26 UTC
Reply
Permalink
If we're going to add this we should add the symmetric operation for

jam :: Either a a -> a

to Data.Either. (Name taken from Conal's compiling to categories code.)

My own code has called these diag and codiag respectively. I happily yield
to a nicer convention.

I have no real preference for whether we do the simple version in
Data.Tuple (which has a lot of precedent, as Data.Tuple tends to have lots
of little simple combinators that could be done more generally as arrows)
or moving it into Control.Arrow.

-Edward
Post by Ivan Perez
Post by Vanessa McHale
According to GHCi,
λ:> import Control.Arrow
λ:> :t (id &&& id)
(id &&& id) :: b -> (b, b)
That is, this implementation has type a -> (a, a) as well.
Yes, yes, that's what I meant by "it works for functions as well (since
they are arrows)"
Ivan
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Oliver Charles
2018-10-28 22:15:29 UTC
Reply
Permalink
jam? Seriously? I'm sure we can do much better wrt names than that.
Even dup I'd rather see expanded to "duplicate". The theory might have
shown that these are useful combinators, but that doesn't mean they
should decide the names.
Post by Edward Kmett
If we're going to add this we should add the symmetric operation for
jam :: Either a a -> a
to Data.Either. (Name taken from Conal's compiling to categories code.)
My own code has called these diag and codiag respectively. I happily yield to a nicer convention.
I have no real preference for whether we do the simple version in Data.Tuple (which has a lot of precedent, as Data.Tuple tends to have lots of little simple combinators that could be done more generally as arrows) or moving it into Control.Arrow.
-Edward
Post by Ivan Perez
Post by Vanessa McHale
According to GHCi,
λ:> import Control.Arrow
λ:> :t (id &&& id)
(id &&& id) :: b -> (b, b)
That is, this implementation has type a -> (a, a) as well.
Yes, yes, that's what I meant by "it works for functions as well (since
they are arrows)"
Ivan
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Edward Kmett
2018-10-28 22:22:02 UTC
Reply
Permalink
I have no strong preference for the name for 'jam', merely the existence of
the dual construction if we're going to name one.

However a needless name conflict with duplicate from Control.Comonad would
be rather unfortunate.

dup as the name for this operation has a ton of precedent in languages like
forth, and its length is comparable to the already smashed fst and snd.

-Edward
Post by Oliver Charles
jam? Seriously? I'm sure we can do much better wrt names than that.
Even dup I'd rather see expanded to "duplicate". The theory might have
shown that these are useful combinators, but that doesn't mean they
should decide the names.
Post by Edward Kmett
If we're going to add this we should add the symmetric operation for
jam :: Either a a -> a
to Data.Either. (Name taken from Conal's compiling to categories code.)
My own code has called these diag and codiag respectively. I happily
yield to a nicer convention.
Post by Edward Kmett
I have no real preference for whether we do the simple version in
Data.Tuple (which has a lot of precedent, as Data.Tuple tends to have lots
of little simple combinators that could be done more generally as arrows)
or moving it into Control.Arrow.
Post by Edward Kmett
-Edward
Post by Ivan Perez
Post by Vanessa McHale
According to GHCi,
λ:> import Control.Arrow
λ:> :t (id &&& id)
(id &&& id) :: b -> (b, b)
That is, this implementation has type a -> (a, a) as well.
Yes, yes, that's what I meant by "it works for functions as well (since
they are arrows)"
Ivan
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Carter Schonwald
2018-10-29 21:29:01 UTC
Reply
Permalink
dup is nice, but i dont really care what we call it as long as its not
annoying or dumbe :)
Post by Edward Kmett
I have no strong preference for the name for 'jam', merely the existence
of the dual construction if we're going to name one.
However a needless name conflict with duplicate from Control.Comonad would
be rather unfortunate.
dup as the name for this operation has a ton of precedent in languages
like forth, and its length is comparable to the already smashed fst and snd.
-Edward
Post by Oliver Charles
jam? Seriously? I'm sure we can do much better wrt names than that.
Even dup I'd rather see expanded to "duplicate". The theory might have
shown that these are useful combinators, but that doesn't mean they
should decide the names.
Post by Edward Kmett
If we're going to add this we should add the symmetric operation for
jam :: Either a a -> a
to Data.Either. (Name taken from Conal's compiling to categories code.)
My own code has called these diag and codiag respectively. I happily
yield to a nicer convention.
Post by Edward Kmett
I have no real preference for whether we do the simple version in
Data.Tuple (which has a lot of precedent, as Data.Tuple tends to have lots
of little simple combinators that could be done more generally as arrows)
or moving it into Control.Arrow.
Post by Edward Kmett
-Edward
Post by Ivan Perez
Post by Vanessa McHale
According to GHCi,
λ:> import Control.Arrow
λ:> :t (id &&& id)
(id &&& id) :: b -> (b, b)
That is, this implementation has type a -> (a, a) as well.
Yes, yes, that's what I meant by "it works for functions as well (since
they are arrows)"
Ivan
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Ivan Perez
2018-10-28 11:56:35 UTC
Reply
Permalink
Post by David Feuer
I'm not opposed.
I don't know what the process it. If others also agree about including
it, could I perhaps be the one submitting the patch?

It would force me to go through the process of contributing to base,
something I've never done.

Cheers

Ivan
Henrik Nilsson
2018-10-28 12:32:40 UTC
Reply
Permalink
Hi,
Post by Ivan Perez
The function \x -> (x,x) is very convenient when working with arrows.
Would it be appropriate to add it to Data.Tuple?
I'm not opposed. Should this be called dup or diagonal? What about
larger tuples?
There is precedent in the arrow literature for calling this function
"dup"
It would indeed be unfortunate if it was not called "dup".

One could argue, as David (I'm guessing) does, that it's a bit of an
odd definition to add to Data.Tuple as it only works for pairs
(as implied by its name).

And the reason it's convenient for Arrows is that (standard) Arrows
are defined in a way that relies on pairs.

So maybe it should somehow be defined in relation with Arrows.

But then again, all other functions in Data.Tuple are at present
specific to pairs ("fst", "snd", "swap", ...).

So "dup" would certainly not look out of place there.


Best,

/Henrik





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment.

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored
where permitted by law.
Ivan Perez
2018-10-28 11:50:14 UTC
Reply
Permalink
Forgot to CC the list.

-------- Forwarded Message --------

Hi,

One place where it pops up all the time is when you have arrows that
create feedback loops and your output is your accumulator.

For example:

feedback acc0 (someFancyArrow >>> arr dup)

Where someFancyArrow is an arrow with two inputs (input and old
accumulator) and one output.

Cheers

Ivan
Post by Vanessa McHale
Out of curiosity, do you have any examples?
Cheers
Post by Ivan Perez
Dear all,
The function \x -> (x,x) is very convenient when working with arrows.
Would it be appropriate to add it to Data.Tuple?
Cheers,
Ivan
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Loading...