Adding dup to Data.Tuple?

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

Adding dup to Data.Tuple?

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

Re: Adding dup to Data.Tuple?

Vanessa McHale
Out of curiosity, do you have any examples?

Cheers

On 10/27/18 5:03 PM, Ivan Perez wrote:

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

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding dup to Data.Tuple?

David Feuer
In reply to this post by Ivan Perez-2
I'm not opposed. Should this be called dup or diagonal? What about larger tuples?

Side note:
\x -> (x,x) = join (,)

On Sat, Oct 27, 2018, 6:03 PM Ivan Perez <[hidden email]> wrote:
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
[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: Adding dup to Data.Tuple?

Dan Burton
There is precedent in the arrow literature for calling this function "dup". For example, on page 55 of this paper:

On Sun, Oct 28, 2018 at 12:48 AM David Feuer <[hidden email]> wrote:
I'm not opposed. Should this be called dup or diagonal? What about larger tuples?

Side note:
\x -> (x,x) = join (,)

On Sat, Oct 27, 2018, 6:03 PM Ivan Perez <[hidden email]> wrote:
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
[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: Adding dup to Data.Tuple?

Dannyu NDos
If this is for convenience for arrows, isn't it better implemented as?:

dup :: Arrow a => a b (b,b)
dup = id &&& id

2018년 10월 28일 (일) 15:03, Dan Burton <[hidden email]>님이 작성:
There is precedent in the arrow literature for calling this function "dup". For example, on page 55 of this paper:

On Sun, Oct 28, 2018 at 12:48 AM David Feuer <[hidden email]> wrote:
I'm not opposed. Should this be called dup or diagonal? What about larger tuples?

Side note:
\x -> (x,x) = join (,)

On Sat, Oct 27, 2018, 6:03 PM Ivan Perez <[hidden email]> wrote:
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
[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: Adding dup to Data.Tuple?

Ivan Perez-2

On 28/10/18 03:51, Dannyu NDos wrote:
> If this is for convenience for arrows, isn't it better implemented as?:
>
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Adding dup to Data.Tuple?

Ivan Perez-2
In reply to this post by David Feuer
On 28/10/18 00:47, David Feuer wrote:
> 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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Adding dup to Data.Tuple?

Henrik Nilsson-2
In reply to this post by David Feuer
Hi,

Ivan Perez wrote:

 > The function \x -> (x,x) is very convenient when working with arrows.
 > Would it be appropriate to add it to Data.Tuple?

David Feuer replied:

 > I'm not opposed. Should this be called dup or diagonal? What about
 > larger tuples?

Dan Burton replied:

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




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

Re: Adding dup to Data.Tuple?

Vanessa McHale
In reply to this post by Ivan Perez-2
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.

On 10/28/18 6:52 AM, Ivan Perez wrote:

>
> On 28/10/18 03:51, Dannyu NDos wrote:
>> If this is for convenience for arrows, isn't it better implemented as?:
>>
>> 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
> [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

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding dup to Data.Tuple?

Ivan Perez-2
On 28/10/18 09:48, Vanessa McHale wrote:
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Adding dup to Data.Tuple?

Edward Kmett-2
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

On Sun, Oct 28, 2018 at 12:07 PM Ivan Perez <[hidden email]> wrote:
On 28/10/18 09:48, Vanessa McHale wrote:
> 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
[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: Adding dup to Data.Tuple?

Oliver Charles-3
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.
On Sun, Oct 28, 2018 at 10:10 PM Edward Kmett <[hidden email]> wrote:

>
> 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
>
> On Sun, Oct 28, 2018 at 12:07 PM Ivan Perez <[hidden email]> wrote:
>>
>> On 28/10/18 09:48, Vanessa McHale wrote:
>> > 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
>> [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: Adding dup to Data.Tuple?

Edward Kmett-2
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


On Sun, Oct 28, 2018 at 6:15 PM Oliver Charles <[hidden email]> wrote:
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.
On Sun, Oct 28, 2018 at 10:10 PM Edward Kmett <[hidden email]> wrote:
>
> 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
>
> On Sun, Oct 28, 2018 at 12:07 PM Ivan Perez <[hidden email]> wrote:
>>
>> On 28/10/18 09:48, Vanessa McHale wrote:
>> > 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
>> [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: Adding dup to Data.Tuple?

Carter Schonwald
dup is nice, but i dont really care what we call it as long as its not annoying or dumbe :)

On Sun, Oct 28, 2018 at 6:22 PM Edward Kmett <[hidden email]> wrote:
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


On Sun, Oct 28, 2018 at 6:15 PM Oliver Charles <[hidden email]> wrote:
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.
On Sun, Oct 28, 2018 at 10:10 PM Edward Kmett <[hidden email]> wrote:
>
> 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
>
> On Sun, Oct 28, 2018 at 12:07 PM Ivan Perez <[hidden email]> wrote:
>>
>> On 28/10/18 09:48, Vanessa McHale wrote:
>> > 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
>> [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