Diagonalization/ dupe for monads and tuples?

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

Diagonalization/ dupe for monads and tuples?

Carter Schonwald
It was pointed out to me in a private communication that the tuple function \x->(x,x) is actually a special case of a diagonalization for biapplicative and some related structures monadicially.  Another example in the same flavor is pure impl for the applicative instance for sized lists. 

diag x = bipure x x 

So framed a litttle differently, there’s definitely an abstraction or common pattern lurking here. Perhaps folks can help Tease this out. One person I chatted with this morning alluded to it being relevant to computational flavors of adjunctions or some such ? It def matters in a different way when doing computation resource aware programming in a symmetric monoidal category.  

Let’s collect some ideas and patterns and get to the bottom of this! 

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

Re: Diagonalization/ dupe for monads and tuples?

M Farkas-Dyck
We also have

diag = join bipure

and (in pseudo-Haskell)

diag = unJoin . pure
  where
    newtype Join f a = Join { unJoin :: f a a } deriving (Functor)
    deriving instance Biapplicative f => Applicative (Join f)

The latter seems on its face potentially related to the instance for
lists of fixed length, but i am not sure how deep the connection may
be.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Diagonalization/ dupe for monads and tuples?

Carter Schonwald
Is the join bipure definition taking advantage of the (a->) monad instance?  Slick!


On Wed, Sep 16, 2020 at 3:39 PM Matthew Farkas-Dyck <[hidden email]> wrote:
We also have



diag = join bipure



and (in pseudo-Haskell)



diag = unJoin . pure

  where

    newtype Join f a = Join { unJoin :: f a a } deriving (Functor)

    deriving instance Biapplicative f => Applicative (Join f)



The latter seems on its face potentially related to the instance for

lists of fixed length, but i am not sure how deep the connection may

be.


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

Re: Diagonalization/ dupe for monads and tuples?

Emily Pillmore
Nice!

That's kind of what I was going for with Carter earlier in the day, thanks Matthew.

I think a diagonalization function and functor are both very sensible additions to `bifunctors` and `Data.Bifunctor`. The theory behind this is sound: The diagonalization functor Δ: Hask → Hask^Hask, forms the center of the adjoint triple `colim -| Δ -| lim : Hask → Hask^Hask`.

Certainly the function `diag :: a → (a,a)` is something I've seen written in several libraries, and should be included in `Data.Tuple` as a `base` function. The clear generalization of this function is `diag :: Biapplicative f ⇒ a → f a a`. I'm in favor of both existing in their separate capacities. 

Thoughts? 

Emily


On Wed, Sep 16, 2020 at 3:49 PM, Carter Schonwald <[hidden email]> wrote:
Is the join bipure definition taking advantage of the (a->) monad instance?  Slick!


On Wed, Sep 16, 2020 at 3:39 PM Matthew Farkas-Dyck <[hidden email]> wrote:
We also have



diag = join bipure



and (in pseudo-Haskell)



diag = unJoin . pure

  where

    newtype Join f a = Join { unJoin :: f a a } deriving (Functor)

    deriving instance Biapplicative f => Applicative (Join f)



The latter seems on its face potentially related to the instance for

lists of fixed length, but i am not sure how deep the connection may

be.

_______________________________________________
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: Diagonalization/ dupe for monads and tuples?

Asad Saeeduddin

Whoops, I just realized I've been responding to Carter specifically instead of to the list.

I was having some trouble understanding the `unJoin` stuff but I read it a few more times and I think I understand it a little better now.

In my personal experience the "abstracted version" of `x -> (x, x)` I use most often looks like this:

```

class SymmetricMonoidal t i p => CartesianMonoidal t i p
  where
  duplicate :: p x (x `t` x)
  discard :: p x i

-- Laws:
-- duplicate >>> first  discard = fwd lunit
-- duplicate >>> second discard = fwd runit

-- where
-- lunit :: Monoidal t i p => Iso p x (i `t` x)
-- runit :: Monoidal t i p => Iso p x (x `t` i)

```

i.e. adding a suitable duplicate and discard to some symmetric monoidal structure gives us a cartesian monoidal structure.

This doesn't really seem to be relevant to what you folks are looking for, but it does bring up a question. If some `Bifunctor` `t` happens to form a monoidal structure on `->`, wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?

On 9/16/20 5:26 PM, Emily Pillmore wrote:
Nice!

That's kind of what I was going for with Carter earlier in the day, thanks Matthew.

I think a diagonalization function and functor are both very sensible additions to `bifunctors` and `Data.Bifunctor`. The theory behind this is sound: The diagonalization functor Δ: Hask → Hask^Hask, forms the center of the adjoint triple `colim -| Δ -| lim : Hask → Hask^Hask`.

Certainly the function `diag :: a → (a,a)` is something I've seen written in several libraries, and should be included in `Data.Tuple` as a `base` function. The clear generalization of this function is `diag :: Biapplicative f ⇒ a → f a a`. I'm in favor of both existing in their separate capacities. 

Thoughts? 

Emily


On Wed, Sep 16, 2020 at 3:49 PM, Carter Schonwald <[hidden email]> wrote:
Is the join bipure definition taking advantage of the (a->) monad instance?  Slick!


On Wed, Sep 16, 2020 at 3:39 PM Matthew Farkas-Dyck <[hidden email]> wrote:
We also have



diag = join bipure



and (in pseudo-Haskell)



diag = unJoin . pure

  where

    newtype Join f a = Join { unJoin :: f a a } deriving (Functor)

    deriving instance Biapplicative f => Applicative (Join f)



The latter seems on its face potentially related to the instance for

lists of fixed length, but i am not sure how deep the connection may

be.

_______________________________________________
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: Diagonalization/ dupe for monads and tuples?

Emily Pillmore
@Asad that's a perfectly reasonable way to think about diagonal operations: as the data of a cartesian monoidal category, and the laws are correct in this case. I think we can get away with the additional abstraction to `Biapplicative` in this case, though.

wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?


Only if you chose that particular unit and that particular arrow. But there are other places where having a general `Biapplicative` contraint would make it useful. For example,  i'd like to use this in `smash` with `diag :: a → Smash a a`, defining the adjoining of a point to `a` and creating a diagonal in the subcategory of pointed spaces in Hask, so that I don't have to redefine this as `diag' = quotSmash . view _CanIso . diag . Just`.

Cheers,
Emily







On Wed, Sep 16, 2020 at 6:35 PM, Asad Saeeduddin <[hidden email]> wrote:

Whoops, I just realized I've been responding to Carter specifically instead of to the list.

I was having some trouble understanding the `unJoin` stuff but I read it a few more times and I think I understand it a little better now.

In my personal experience the "abstracted version" of `x -> (x, x)` I use most often looks like this:

```

class SymmetricMonoidal t i p => CartesianMonoidal t i p
  where
  duplicate :: p x (x `t` x)
  discard :: p x i

-- Laws:
-- duplicate >>> first  discard = fwd lunit
-- duplicate >>> second discard = fwd runit

-- where
-- lunit :: Monoidal t i p => Iso p x (i `t` x)
-- runit :: Monoidal t i p => Iso p x (x `t` i)

```

i.e. adding a suitable duplicate and discard to some symmetric monoidal structure gives us a cartesian monoidal structure.

This doesn't really seem to be relevant to what you folks are looking for, but it does bring up a question. If some `Bifunctor` `t` happens to form a monoidal structure on `->`, wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?

On 9/16/20 5:26 PM, Emily Pillmore wrote:
Nice!

That's kind of what I was going for with Carter earlier in the day, thanks Matthew.

I think a diagonalization function and functor are both very sensible additions to `bifunctors` and `Data.Bifunctor`. The theory behind this is sound: The diagonalization functor Δ: Hask → Hask^Hask, forms the center of the adjoint triple `colim -| Δ -| lim : Hask → Hask^Hask`.

Certainly the function `diag :: a → (a,a)` is something I've seen written in several libraries, and should be included in `Data.Tuple` as a `base` function. The clear generalization of this function is `diag :: Biapplicative f ⇒ a → f a a`. I'm in favor of both existing in their separate capacities. 

Thoughts? 

Emily


On Wed, Sep 16, 2020 at 3:49 PM, Carter Schonwald <[hidden email]> wrote:
Is the join bipure definition taking advantage of the (a->) monad instance?  Slick!


On Wed, Sep 16, 2020 at 3:39 PM Matthew Farkas-Dyck <[hidden email]> wrote:
We also have



diag = join bipure



and (in pseudo-Haskell)



diag = unJoin . pure

  where

    newtype Join f a = Join { unJoin :: f a a } deriving (Functor)

    deriving instance Biapplicative f => Applicative (Join f)



The latter seems on its face potentially related to the instance for

lists of fixed length, but i am not sure how deep the connection may

be.

_______________________________________________
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: Diagonalization/ dupe for monads and tuples?

Emily Pillmore
Just to clarify, that's not the "real" diagonal in the space, but it is a super useful translation that I'd like for free :)


On Wed, Sep 16, 2020 at 9:08 PM, Emily Pillmore <[hidden email]> wrote:
@Asad that's a perfectly reasonable way to think about diagonal operations: as the data of a cartesian monoidal category, and the laws are correct in this case. I think we can get away with the additional abstraction to `Biapplicative` in this case, though.

wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?


Only if you chose that particular unit and that particular arrow. But there are other places where having a general `Biapplicative` contraint would make it useful. For example,  i'd like to use this in `smash` with `diag :: a → Smash a a`, defining the adjoining of a point to `a` and creating a diagonal in the subcategory of pointed spaces in Hask, so that I don't have to redefine this as `diag' = quotSmash . view _CanIso . diag . Just`.

Cheers,
Emily







On Wed, Sep 16, 2020 at 6:35 PM, Asad Saeeduddin <[hidden email]> wrote:

Whoops, I just realized I've been responding to Carter specifically instead of to the list.

I was having some trouble understanding the `unJoin` stuff but I read it a few more times and I think I understand it a little better now.

In my personal experience the "abstracted version" of `x -> (x, x)` I use most often looks like this:

```

class SymmetricMonoidal t i p => CartesianMonoidal t i p
  where
  duplicate :: p x (x `t` x)
  discard :: p x i

-- Laws:
-- duplicate >>> first  discard = fwd lunit
-- duplicate >>> second discard = fwd runit

-- where
-- lunit :: Monoidal t i p => Iso p x (i `t` x)
-- runit :: Monoidal t i p => Iso p x (x `t` i)

```

i.e. adding a suitable duplicate and discard to some symmetric monoidal structure gives us a cartesian monoidal structure.

This doesn't really seem to be relevant to what you folks are looking for, but it does bring up a question. If some `Bifunctor` `t` happens to form a monoidal structure on `->`, wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?

On 9/16/20 5:26 PM, Emily Pillmore wrote:
Nice!

That's kind of what I was going for with Carter earlier in the day, thanks Matthew.

I think a diagonalization function and functor are both very sensible additions to `bifunctors` and `Data.Bifunctor`. The theory behind this is sound: The diagonalization functor Δ: Hask → Hask^Hask, forms the center of the adjoint triple `colim -| Δ -| lim : Hask → Hask^Hask`.

Certainly the function `diag :: a → (a,a)` is something I've seen written in several libraries, and should be included in `Data.Tuple` as a `base` function. The clear generalization of this function is `diag :: Biapplicative f ⇒ a → f a a`. I'm in favor of both existing in their separate capacities. 

Thoughts? 

Emily


On Wed, Sep 16, 2020 at 3:49 PM, Carter Schonwald <[hidden email]> wrote:
Is the join bipure definition taking advantage of the (a->) monad instance?  Slick!


On Wed, Sep 16, 2020 at 3:39 PM Matthew Farkas-Dyck <[hidden email]> wrote:
We also have



diag = join bipure



and (in pseudo-Haskell)



diag = unJoin . pure

  where

    newtype Join f a = Join { unJoin :: f a a } deriving (Functor)

    deriving instance Biapplicative f => Applicative (Join f)



The latter seems on its face potentially related to the instance for

lists of fixed length, but i am not sure how deep the connection may

be.

_______________________________________________
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: Diagonalization/ dupe for monads and tuples?

Edward Kmett-2
For what it's worth, I'd just like to see a no-nonsense 

dup : a -> (a,a)
dup a = (a,a)

in Data.Tuple, where it is out of the way, but right where you'd expect it to be when looking for something for working with tuples.

Yes, bipure and id &&& id exist, and generalize it on two incompatible axes, and if we had a proper cartesian category we'd be able to supply this in full generality, as a morphism to the diagonal functor, but all of these require a level of rocket science to figure out.

I'd also happily support adding the equivalent in Data.Either for Either a a -> a, which invites bikeshedding names.

-Edward

On Wed, Sep 16, 2020 at 6:10 PM Emily Pillmore <[hidden email]> wrote:
Just to clarify, that's not the "real" diagonal in the space, but it is a super useful translation that I'd like for free :)


On Wed, Sep 16, 2020 at 9:08 PM, Emily Pillmore <[hidden email]> wrote:
@Asad that's a perfectly reasonable way to think about diagonal operations: as the data of a cartesian monoidal category, and the laws are correct in this case. I think we can get away with the additional abstraction to `Biapplicative` in this case, though.

wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?


Only if you chose that particular unit and that particular arrow. But there are other places where having a general `Biapplicative` contraint would make it useful. For example,  i'd like to use this in `smash` with `diag :: a → Smash a a`, defining the adjoining of a point to `a` and creating a diagonal in the subcategory of pointed spaces in Hask, so that I don't have to redefine this as `diag' = quotSmash . view _CanIso . diag . Just`.

Cheers,
Emily







On Wed, Sep 16, 2020 at 6:35 PM, Asad Saeeduddin <[hidden email]> wrote:

Whoops, I just realized I've been responding to Carter specifically instead of to the list.

I was having some trouble understanding the `unJoin` stuff but I read it a few more times and I think I understand it a little better now.

In my personal experience the "abstracted version" of `x -> (x, x)` I use most often looks like this:

```

class SymmetricMonoidal t i p => CartesianMonoidal t i p
  where
  duplicate :: p x (x `t` x)
  discard :: p x i

-- Laws:
-- duplicate >>> first  discard = fwd lunit
-- duplicate >>> second discard = fwd runit

-- where
-- lunit :: Monoidal t i p => Iso p x (i `t` x)
-- runit :: Monoidal t i p => Iso p x (x `t` i)

```

i.e. adding a suitable duplicate and discard to some symmetric monoidal structure gives us a cartesian monoidal structure.

This doesn't really seem to be relevant to what you folks are looking for, but it does bring up a question. If some `Bifunctor` `t` happens to form a monoidal structure on `->`, wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?

On 9/16/20 5:26 PM, Emily Pillmore wrote:
Nice!

That's kind of what I was going for with Carter earlier in the day, thanks Matthew.

I think a diagonalization function and functor are both very sensible additions to `bifunctors` and `Data.Bifunctor`. The theory behind this is sound: The diagonalization functor Δ: Hask → Hask^Hask, forms the center of the adjoint triple `colim -| Δ -| lim : Hask → Hask^Hask`.

Certainly the function `diag :: a → (a,a)` is something I've seen written in several libraries, and should be included in `Data.Tuple` as a `base` function. The clear generalization of this function is `diag :: Biapplicative f ⇒ a → f a a`. I'm in favor of both existing in their separate capacities. 

Thoughts? 

Emily


On Wed, Sep 16, 2020 at 3:49 PM, Carter Schonwald <[hidden email]> wrote:
Is the join bipure definition taking advantage of the (a->) monad instance?  Slick!


On Wed, Sep 16, 2020 at 3:39 PM Matthew Farkas-Dyck <[hidden email]> wrote:
We also have



diag = join bipure



and (in pseudo-Haskell)



diag = unJoin . pure

  where

    newtype Join f a = Join { unJoin :: f a a } deriving (Functor)

    deriving instance Biapplicative f => Applicative (Join f)



The latter seems on its face potentially related to the instance for

lists of fixed length, but i am not sure how deep the connection may

be.

_______________________________________________
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

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

Re: Diagonalization/ dupe for monads and tuples?

Asad Saeeduddin

`Either a a -> a` is another very handy operation. That and `a -> (a, a)` together make up 90% of use cases for `duplicate :: p x (t x x)`.

On 9/17/20 12:49 AM, Edward Kmett wrote:
For what it's worth, I'd just like to see a no-nonsense 

dup : a -> (a,a)
dup a = (a,a)

in Data.Tuple, where it is out of the way, but right where you'd expect it to be when looking for something for working with tuples.

Yes, bipure and id &&& id exist, and generalize it on two incompatible axes, and if we had a proper cartesian category we'd be able to supply this in full generality, as a morphism to the diagonal functor, but all of these require a level of rocket science to figure out.

I'd also happily support adding the equivalent in Data.Either for Either a a -> a, which invites bikeshedding names.

-Edward

On Wed, Sep 16, 2020 at 6:10 PM Emily Pillmore <[hidden email]> wrote:
Just to clarify, that's not the "real" diagonal in the space, but it is a super useful translation that I'd like for free :)


On Wed, Sep 16, 2020 at 9:08 PM, Emily Pillmore <[hidden email]> wrote:
@Asad that's a perfectly reasonable way to think about diagonal operations: as the data of a cartesian monoidal category, and the laws are correct in this case. I think we can get away with the additional abstraction to `Biapplicative` in this case, though.

wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?


Only if you chose that particular unit and that particular arrow. But there are other places where having a general `Biapplicative` contraint would make it useful. For example,  i'd like to use this in `smash` with `diag :: a → Smash a a`, defining the adjoining of a point to `a` and creating a diagonal in the subcategory of pointed spaces in Hask, so that I don't have to redefine this as `diag' = quotSmash . view _CanIso . diag . Just`.

Cheers,
Emily







On Wed, Sep 16, 2020 at 6:35 PM, Asad Saeeduddin <[hidden email]> wrote:

Whoops, I just realized I've been responding to Carter specifically instead of to the list.

I was having some trouble understanding the `unJoin` stuff but I read it a few more times and I think I understand it a little better now.

In my personal experience the "abstracted version" of `x -> (x, x)` I use most often looks like this:

```

class SymmetricMonoidal t i p => CartesianMonoidal t i p
  where
  duplicate :: p x (x `t` x)
  discard :: p x i

-- Laws:
-- duplicate >>> first  discard = fwd lunit
-- duplicate >>> second discard = fwd runit

-- where
-- lunit :: Monoidal t i p => Iso p x (i `t` x)
-- runit :: Monoidal t i p => Iso p x (x `t` i)

```

i.e. adding a suitable duplicate and discard to some symmetric monoidal structure gives us a cartesian monoidal structure.

This doesn't really seem to be relevant to what you folks are looking for, but it does bring up a question. If some `Bifunctor` `t` happens to form a monoidal structure on `->`, wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?

On 9/16/20 5:26 PM, Emily Pillmore wrote:
Nice!

That's kind of what I was going for with Carter earlier in the day, thanks Matthew.

I think a diagonalization function and functor are both very sensible additions to `bifunctors` and `Data.Bifunctor`. The theory behind this is sound: The diagonalization functor Δ: Hask → Hask^Hask, forms the center of the adjoint triple `colim -| Δ -| lim : Hask → Hask^Hask`.

Certainly the function `diag :: a → (a,a)` is something I've seen written in several libraries, and should be included in `Data.Tuple` as a `base` function. The clear generalization of this function is `diag :: Biapplicative f ⇒ a → f a a`. I'm in favor of both existing in their separate capacities. 

Thoughts? 

Emily


On Wed, Sep 16, 2020 at 3:49 PM, Carter Schonwald <[hidden email]> wrote:
Is the join bipure definition taking advantage of the (a->) monad instance?  Slick!


On Wed, Sep 16, 2020 at 3:39 PM Matthew Farkas-Dyck <[hidden email]> wrote:
We also have



diag = join bipure



and (in pseudo-Haskell)



diag = unJoin . pure

  where

    newtype Join f a = Join { unJoin :: f a a } deriving (Functor)

    deriving instance Biapplicative f => Applicative (Join f)



The latter seems on its face potentially related to the instance for

lists of fixed length, but i am not sure how deep the connection may

be.

_______________________________________________
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

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

Re: Diagonalization/ dupe for monads and tuples?

Emily Pillmore
Proposing the following names then to start, and we can talk about expanding this at a later date: 

```
-- In Data.Tuple
diag :: a → (a,a)
diag a = (a, a)

-- In Data.Either
codiag :: Either a a → a
codiag = either id id
```

Thoughts?
Emily



On Thu, Sep 17, 2020 at 12:55 AM, Asad Saeeduddin <[hidden email]> wrote:

`Either a a -> a` is another very handy operation. That and `a -> (a, a)` together make up 90% of use cases for `duplicate :: p x (t x x)`.

On 9/17/20 12:49 AM, Edward Kmett wrote:
For what it's worth, I'd just like to see a no-nonsense 

dup : a -> (a,a)
dup a = (a,a)

in Data.Tuple, where it is out of the way, but right where you'd expect it to be when looking for something for working with tuples.

Yes, bipure and id &&& id exist, and generalize it on two incompatible axes, and if we had a proper cartesian category we'd be able to supply this in full generality, as a morphism to the diagonal functor, but all of these require a level of rocket science to figure out.

I'd also happily support adding the equivalent in Data.Either for Either a a -> a, which invites bikeshedding names.

-Edward

On Wed, Sep 16, 2020 at 6:10 PM Emily Pillmore <[hidden email]> wrote:
Just to clarify, that's not the "real" diagonal in the space, but it is a super useful translation that I'd like for free :)


On Wed, Sep 16, 2020 at 9:08 PM, Emily Pillmore <[hidden email]> wrote:
@Asad that's a perfectly reasonable way to think about diagonal operations: as the data of a cartesian monoidal category, and the laws are correct in this case. I think we can get away with the additional abstraction to `Biapplicative` in this case, though.

wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?


Only if you chose that particular unit and that particular arrow. But there are other places where having a general `Biapplicative` contraint would make it useful. For example,  i'd like to use this in `smash` with `diag :: a → Smash a a`, defining the adjoining of a point to `a` and creating a diagonal in the subcategory of pointed spaces in Hask, so that I don't have to redefine this as `diag' = quotSmash . view _CanIso . diag . Just`.

Cheers,
Emily







On Wed, Sep 16, 2020 at 6:35 PM, Asad Saeeduddin <[hidden email]> wrote:

Whoops, I just realized I've been responding to Carter specifically instead of to the list.

I was having some trouble understanding the `unJoin` stuff but I read it a few more times and I think I understand it a little better now.

In my personal experience the "abstracted version" of `x -> (x, x)` I use most often looks like this:

```

class SymmetricMonoidal t i p => CartesianMonoidal t i p
  where
  duplicate :: p x (x `t` x)
  discard :: p x i

-- Laws:
-- duplicate >>> first  discard = fwd lunit
-- duplicate >>> second discard = fwd runit

-- where
-- lunit :: Monoidal t i p => Iso p x (i `t` x)
-- runit :: Monoidal t i p => Iso p x (x `t` i)

```

i.e. adding a suitable duplicate and discard to some symmetric monoidal structure gives us a cartesian monoidal structure.

This doesn't really seem to be relevant to what you folks are looking for, but it does bring up a question. If some `Bifunctor` `t` happens to form a monoidal structure on `->`, wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?

On 9/16/20 5:26 PM, Emily Pillmore wrote:
Nice!

That's kind of what I was going for with Carter earlier in the day, thanks Matthew.

I think a diagonalization function and functor are both very sensible additions to `bifunctors` and `Data.Bifunctor`. The theory behind this is sound: The diagonalization functor Δ: Hask → Hask^Hask, forms the center of the adjoint triple `colim -| Δ -| lim : Hask → Hask^Hask`.

Certainly the function `diag :: a → (a,a)` is something I've seen written in several libraries, and should be included in `Data.Tuple` as a `base` function. The clear generalization of this function is `diag :: Biapplicative f ⇒ a → f a a`. I'm in favor of both existing in their separate capacities. 

Thoughts? 

Emily


On Wed, Sep 16, 2020 at 3:49 PM, Carter Schonwald <[hidden email]> wrote:
Is the join bipure definition taking advantage of the (a->) monad instance?  Slick!


On Wed, Sep 16, 2020 at 3:39 PM Matthew Farkas-Dyck <[hidden email]> wrote:
We also have



diag = join bipure



and (in pseudo-Haskell)



diag = unJoin . pure

  where

    newtype Join f a = Join { unJoin :: f a a } deriving (Functor)

    deriving instance Biapplicative f => Applicative (Join f)



The latter seems on its face potentially related to the instance for

lists of fixed length, but i am not sure how deep the connection may

be.

_______________________________________________
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


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

Re: Diagonalization/ dupe for monads and tuples?

chessai .
dup and dedup? Just throwing out names. Not sure I'm a fan of diag/coding.

On Thu, Sep 17, 2020, 00:10 Emily Pillmore <[hidden email]> wrote:
Proposing the following names then to start, and we can talk about expanding this at a later date: 

```
-- In Data.Tuple
diag :: a → (a,a)
diag a = (a, a)

-- In Data.Either
codiag :: Either a a → a
codiag = either id id
```

Thoughts?
Emily



On Thu, Sep 17, 2020 at 12:55 AM, Asad Saeeduddin <[hidden email]> wrote:

`Either a a -> a` is another very handy operation. That and `a -> (a, a)` together make up 90% of use cases for `duplicate :: p x (t x x)`.

On 9/17/20 12:49 AM, Edward Kmett wrote:
For what it's worth, I'd just like to see a no-nonsense 

dup : a -> (a,a)
dup a = (a,a)

in Data.Tuple, where it is out of the way, but right where you'd expect it to be when looking for something for working with tuples.

Yes, bipure and id &&& id exist, and generalize it on two incompatible axes, and if we had a proper cartesian category we'd be able to supply this in full generality, as a morphism to the diagonal functor, but all of these require a level of rocket science to figure out.

I'd also happily support adding the equivalent in Data.Either for Either a a -> a, which invites bikeshedding names.

-Edward

On Wed, Sep 16, 2020 at 6:10 PM Emily Pillmore <[hidden email]> wrote:
Just to clarify, that's not the "real" diagonal in the space, but it is a super useful translation that I'd like for free :)


On Wed, Sep 16, 2020 at 9:08 PM, Emily Pillmore <[hidden email]> wrote:
@Asad that's a perfectly reasonable way to think about diagonal operations: as the data of a cartesian monoidal category, and the laws are correct in this case. I think we can get away with the additional abstraction to `Biapplicative` in this case, though.

wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?


Only if you chose that particular unit and that particular arrow. But there are other places where having a general `Biapplicative` contraint would make it useful. For example,  i'd like to use this in `smash` with `diag :: a → Smash a a`, defining the adjoining of a point to `a` and creating a diagonal in the subcategory of pointed spaces in Hask, so that I don't have to redefine this as `diag' = quotSmash . view _CanIso . diag . Just`.

Cheers,
Emily







On Wed, Sep 16, 2020 at 6:35 PM, Asad Saeeduddin <[hidden email]> wrote:

Whoops, I just realized I've been responding to Carter specifically instead of to the list.

I was having some trouble understanding the `unJoin` stuff but I read it a few more times and I think I understand it a little better now.

In my personal experience the "abstracted version" of `x -> (x, x)` I use most often looks like this:

```

class SymmetricMonoidal t i p => CartesianMonoidal t i p
  where
  duplicate :: p x (x `t` x)
  discard :: p x i

-- Laws:
-- duplicate >>> first  discard = fwd lunit
-- duplicate >>> second discard = fwd runit

-- where
-- lunit :: Monoidal t i p => Iso p x (i `t` x)
-- runit :: Monoidal t i p => Iso p x (x `t` i)

```

i.e. adding a suitable duplicate and discard to some symmetric monoidal structure gives us a cartesian monoidal structure.

This doesn't really seem to be relevant to what you folks are looking for, but it does bring up a question. If some `Bifunctor` `t` happens to form a monoidal structure on `->`, wouldn't the existence of appropriate `forall a. a -> t a a` and `forall a. x -> Unit t` functions pigeonhole it into being "the" cartesian monoidal structure on `->` (and thus naturally isomorphic to `(,)`)?

On 9/16/20 5:26 PM, Emily Pillmore wrote:
Nice!

That's kind of what I was going for with Carter earlier in the day, thanks Matthew.

I think a diagonalization function and functor are both very sensible additions to `bifunctors` and `Data.Bifunctor`. The theory behind this is sound: The diagonalization functor Δ: Hask → Hask^Hask, forms the center of the adjoint triple `colim -| Δ -| lim : Hask → Hask^Hask`.

Certainly the function `diag :: a → (a,a)` is something I've seen written in several libraries, and should be included in `Data.Tuple` as a `base` function. The clear generalization of this function is `diag :: Biapplicative f ⇒ a → f a a`. I'm in favor of both existing in their separate capacities. 

Thoughts? 

Emily


On Wed, Sep 16, 2020 at 3:49 PM, Carter Schonwald <[hidden email]> wrote:
Is the join bipure definition taking advantage of the (a->) monad instance?  Slick!


On Wed, Sep 16, 2020 at 3:39 PM Matthew Farkas-Dyck <[hidden email]> wrote:
We also have



diag = join bipure



and (in pseudo-Haskell)



diag = unJoin . pure

  where

    newtype Join f a = Join { unJoin :: f a a } deriving (Functor)

    deriving instance Biapplicative f => Applicative (Join f)



The latter seems on its face potentially related to the instance for

lists of fixed length, but i am not sure how deep the connection may

be.

_______________________________________________
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

_______________________________________________
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: Diagonalization/ dupe for monads and tuples?

Carter Schonwald
For the tuple monomorphic one id probably ageee with Dan.  

On Thu, Sep 17, 2020 at 1:13 AM chessai <[hidden email]> wrote:
dup and dedup? Just throwing out names. Not sure I'm a fan of diag/coding.

On Thu, Sep 17, 2020, 00:10 Emily Pillmore <[hidden email]> wrote:
Proposing the following names then to start, and we can talk about expanding this at a later date: 

```
-- In Data.Tuple
diag :: a → (a,a)
diag a = (a, a)

-- In Data.Either
codiag :: Either a a → a
codiag = either id id
```

Thoughts?
Emily



On Thu, Sep 17, 2020 at 12:55 AM, Asad Saeeduddin <[hidden email]> wrote:

`Either a a -> a` is another very handy operation. That and `a

-> (a, a)` together make up 90% of use cases for `duplicate ::

p x (t x x)`.




On 9/17/20 12:49 AM, Edward Kmett

wrote:








For what it's worth, I'd just like to see a

no-nonsense 






dup : a -> (a,a)


dup a = (a,a)







in Data.Tuple, where it is

out of the way, but right where you'd expect it to be when

looking for something for working with tuples.







Yes, bipure and id &&& id exist, and

generalize it on two incompatible axes, and if we had a proper

cartesian category we'd be able to supply this in full

generality, as a morphism to the diagonal functor, but all of

these require a level of rocket science to figure out.







I'd also happily support adding the equivalent in Data.Either for Either a a -> a, which invites

bikeshedding names.







-Edward









On Wed, Sep 16, 2020 at 6:10

PM Emily Pillmore <[hidden email]> wrote:


















Just to clarify, that's not the "real" diagonal

in the space, but it is a super useful translation

that I'd like for free :)














On Wed, Sep 16, 2020 at 9:08

PM, Emily Pillmore <[hidden email]>

wrote:














@Asad that's a perfectly reasonable

way to think about diagonal

operations: as the data of a cartesian

monoidal category, and the laws are

correct in this case. I think we can

get away with the additional

abstraction to `Biapplicative` in this

case, though.





























wouldn't

the existence of

appropriate

`forall a. a ->

t a a` and `forall

a. x -> Unit t`

functions

pigeonhole it into

being "the"

cartesian monoidal

structure on

`->` (and thus

naturally

isomorphic to

`(,)`)?































Only if you chose that particular

unit and that particular arrow. But

there are other places where having

a general `Biapplicative` contraint

would make it useful. For example,

 i'd like to use this in `smash`

with `diag :: a → Smash a a`,

defining the adjoining of a point to

`a` and creating a diagonal in the

subcategory of pointed spaces in

Hask, so that I don't have to

redefine this as `diag' = quotSmash

. view _CanIso . diag . Just`.









Cheers,




Emily









































On Wed, Sep 16,

2020 at 6:35 PM, Asad Saeeduddin <[hidden email]>

wrote:








Whoops, I just realized I've

been responding to Carter

specifically instead of to the

list.





I was having some trouble

understanding the `unJoin` stuff

but I read it a few more times

and I think I understand it a

little better now.





In my personal experience the

"abstracted version" of `x ->

(x, x)` I use most often looks

like this:





```




class SymmetricMonoidal t i p => CartesianMonoidal t i p


  where


  duplicate :: p x (x `t` x)


  discard :: p x i





-- Laws:


-- duplicate >>> first  discard = fwd lunit


-- duplicate >>> second discard = fwd runit





-- where


-- lunit :: Monoidal t i p => Iso p x (i `t` x)


-- runit :: Monoidal t i p => Iso p x (x `t` i)


```





i.e. adding a suitable duplicate

and discard to some symmetric

monoidal structure gives us a

cartesian monoidal structure.





This doesn't really seem to be

relevant to what you folks are

looking for, but it does bring

up a question. If some

`Bifunctor` `t` happens to form

a monoidal structure on `->`,

wouldn't the existence of

appropriate `forall a. a -> t

a a` and `forall a. x -> Unit

t` functions pigeonhole it into

being "the" cartesian monoidal

structure on `->` (and thus

naturally isomorphic to `(,)`)?



On 9/16/20 5:26 PM, Emily

Pillmore wrote:














Nice!





That's kind of what I

was going for with

Carter earlier in the

day, thanks Matthew.







I think a

diagonalization

function and functor

are both very sensible

additions to

`bifunctors` and

`Data.Bifunctor`. The

theory behind this is

sound: The

diagonalization

functor Δ: Hask →

Hask^Hask, forms the

center of the adjoint

triple `colim -| Δ -|

lim : Hask →

Hask^Hask`.





Certainly the function

`diag :: a → (a,a)` is

something I've seen

written in several

libraries, and should

be included in

`Data.Tuple` as a

`base` function. The

clear generalization

of this function is

`diag :: Biapplicative

f ⇒ a → f a a`. I'm in

favor of both existing

in their separate

capacities. 







Thoughts? 









Emily














On

Wed, Sep 16, 2020 at

3:49 PM, Carter

Schonwald <[hidden email]>

wrote:








Is

the join bipure

definition

taking advantage

of the (a->)

monad instance? 

Slick!
















On

Wed, Sep 16,

2020 at 3:39

PM Matthew

Farkas-Dyck

<[hidden email]> wrote:




We also have











diag = join

bipure











and (in

pseudo-Haskell)











diag = unJoin

. pure





  where





    newtype

Join f a =

Join { unJoin

:: f a a }

deriving

(Functor)





    deriving

instance

Biapplicative

f =>

Applicative

(Join f)











The latter

seems on its

face

potentially

related to the

instance for





lists of fixed

length, but i

am not sure

how deep the

connection may





be.











_______________________________________________




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

_______________________________________________


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: Diagonalization/ dupe for monads and tuples?

Jon Purdy
I’m strongly for these:

Data.Tuple.dup :: a → (a, a)

Data.Either.fromEither :: Either a a → a

These names have precedent in several existing packages, and they’re straightforward to explain in context: ‘dup’ is short for “duplicate” and appears in other contexts like stack languages and (not coincidentally) some category theory; ‘fromEither’ is the obvious thing missing from ________ : ‘either’ :: ‘fromMaybe’ : ‘maybe’.

(The only alternatives I would sincerely propose are ‘copy’ and ‘merge’, but those are less specialised, and so less illustrative. Copy a file? Merge two lists?)

I don’t feel that strongly about the names of the hypothetical generalisations, and indeed it depends on which way(s) they get generalised.

I like ‘diag’ and ‘codiag’ well enough for categorical/arrow combinators, as long as they’re not the names of the simplified/specialised versions.

On Wed, Sep 16, 2020, 10:20 PM Carter Schonwald <[hidden email]> wrote:
For the tuple monomorphic one id probably ageee with Dan.  

On Thu, Sep 17, 2020 at 1:13 AM chessai <[hidden email]> wrote:
dup and dedup? Just throwing out names. Not sure I'm a fan of diag/coding.

On Thu, Sep 17, 2020, 00:10 Emily Pillmore <[hidden email]> wrote:
Proposing the following names then to start, and we can talk about expanding this at a later date: 

```
-- In Data.Tuple
diag :: a → (a,a)
diag a = (a, a)

-- In Data.Either
codiag :: Either a a → a
codiag = either id id
```

Thoughts?
Emily



On Thu, Sep 17, 2020 at 12:55 AM, Asad Saeeduddin <[hidden email]> wrote:

`Either a a -> a` is another very handy operation. That and `a

-> (a, a)` together make up 90% of use cases for `duplicate ::

p x (t x x)`.




On 9/17/20 12:49 AM, Edward Kmett

wrote:








For what it's worth, I'd just like to see a

no-nonsense 






dup : a -> (a,a)


dup a = (a,a)







in Data.Tuple, where it is

out of the way, but right where you'd expect it to be when

looking for something for working with tuples.







Yes, bipure and id &&& id exist, and

generalize it on two incompatible axes, and if we had a proper

cartesian category we'd be able to supply this in full

generality, as a morphism to the diagonal functor, but all of

these require a level of rocket science to figure out.







I'd also happily support adding the equivalent in Data.Either for Either a a -> a, which invites

bikeshedding names.







-Edward









On Wed, Sep 16, 2020 at 6:10

PM Emily Pillmore <[hidden email]> wrote:


















Just to clarify, that's not the "real" diagonal

in the space, but it is a super useful translation

that I'd like for free :)














On Wed, Sep 16, 2020 at 9:08

PM, Emily Pillmore <[hidden email]>

wrote:














@Asad that's a perfectly reasonable

way to think about diagonal

operations: as the data of a cartesian

monoidal category, and the laws are

correct in this case. I think we can

get away with the additional

abstraction to `Biapplicative` in this

case, though.





























wouldn't

the existence of

appropriate

`forall a. a ->

t a a` and `forall

a. x -> Unit t`

functions

pigeonhole it into

being "the"

cartesian monoidal

structure on

`->` (and thus

naturally

isomorphic to

`(,)`)?































Only if you chose that particular

unit and that particular arrow. But

there are other places where having

a general `Biapplicative` contraint

would make it useful. For example,

 i'd like to use this in `smash`

with `diag :: a → Smash a a`,

defining the adjoining of a point to

`a` and creating a diagonal in the

subcategory of pointed spaces in

Hask, so that I don't have to

redefine this as `diag' = quotSmash

. view _CanIso . diag . Just`.









Cheers,




Emily









































On Wed, Sep 16,

2020 at 6:35 PM, Asad Saeeduddin <[hidden email]>

wrote:








Whoops, I just realized I've

been responding to Carter

specifically instead of to the

list.





I was having some trouble

understanding the `unJoin` stuff

but I read it a few more times

and I think I understand it a

little better now.





In my personal experience the

"abstracted version" of `x ->

(x, x)` I use most often looks

like this:





```




class SymmetricMonoidal t i p => CartesianMonoidal t i p


  where


  duplicate :: p x (x `t` x)


  discard :: p x i





-- Laws:


-- duplicate >>> first  discard = fwd lunit


-- duplicate >>> second discard = fwd runit





-- where


-- lunit :: Monoidal t i p => Iso p x (i `t` x)


-- runit :: Monoidal t i p => Iso p x (x `t` i)


```





i.e. adding a suitable duplicate

and discard to some symmetric

monoidal structure gives us a

cartesian monoidal structure.





This doesn't really seem to be

relevant to what you folks are

looking for, but it does bring

up a question. If some

`Bifunctor` `t` happens to form

a monoidal structure on `->`,

wouldn't the existence of

appropriate `forall a. a -> t

a a` and `forall a. x -> Unit

t` functions pigeonhole it into

being "the" cartesian monoidal

structure on `->` (and thus

naturally isomorphic to `(,)`)?



On 9/16/20 5:26 PM, Emily

Pillmore wrote:














Nice!





That's kind of what I

was going for with

Carter earlier in the

day, thanks Matthew.







I think a

diagonalization

function and functor

are both very sensible

additions to

`bifunctors` and

`Data.Bifunctor`. The

theory behind this is

sound: The

diagonalization

functor Δ: Hask →

Hask^Hask, forms the

center of the adjoint

triple `colim -| Δ -|

lim : Hask →

Hask^Hask`.





Certainly the function

`diag :: a → (a,a)` is

something I've seen

written in several

libraries, and should

be included in

`Data.Tuple` as a

`base` function. The

clear generalization

of this function is

`diag :: Biapplicative

f ⇒ a → f a a`. I'm in

favor of both existing

in their separate

capacities. 







Thoughts? 









Emily














On

Wed, Sep 16, 2020 at

3:49 PM, Carter

Schonwald <[hidden email]>

wrote:








Is

the join bipure

definition

taking advantage

of the (a->)

monad instance? 

Slick!
















On

Wed, Sep 16,

2020 at 3:39

PM Matthew

Farkas-Dyck

<[hidden email]> wrote:




We also have











diag = join

bipure











and (in

pseudo-Haskell)











diag = unJoin

. pure





  where





    newtype

Join f a =

Join { unJoin

:: f a a }

deriving

(Functor)





    deriving

instance

Biapplicative

f =>

Applicative

(Join f)











The latter

seems on its

face

potentially

related to the

instance for





lists of fixed

length, but i

am not sure

how deep the

connection may





be.











_______________________________________________




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

_______________________________________________


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: Diagonalization/ dupe for monads and tuples?

Georgi Lyubenov
+1 for Data.Tuple.dup and Data.Either.fromEither

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

Re: Diagonalization/ dupe for monads and tuples?

Ben Franksen
In reply to this post by Edward Kmett-2
Am 17.09.20 um 06:49 schrieb Edward Kmett:

> For what it's worth, I'd just like to see a no-nonsense
>
> dup : a -> (a,a)
> dup a = (a,a)
>
> in Data.Tuple, where it is out of the way, but right where you'd expect it
> to be when looking for something for working with tuples.
>
> Yes, bipure and id &&& id exist, and generalize it on two incompatible
> axes, and if we had a proper cartesian category we'd be able to supply this
> in full generality, as a morphism to the diagonal functor, but all of these
> require a level of rocket science to figure out.

+1

Cheers
Ben

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

Re: Diagonalization/ dupe for monads and tuples?

Oliver Charles-3
In reply to this post by Jon Purdy
Regardless of having a more abstract version, I'm +1 on Jon's suggestion, and those names. fromEither is something I have reached for many many times and been surprised it's not within arms reach.

On Thu, 17 Sep 2020, at 7:16 AM, Jon Purdy wrote:
I’m strongly for these:

Data.Tuple.dup :: a → (a, a)

Data.Either.fromEither :: Either a a → a

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

Re: Diagonalization/ dupe for monads and tuples?

Carter Schonwald
I’d expect fromEither to be 
Either a b -> (a-> c )-> (b-> c) -> c 

Nothing about the name fromEither is suggestive of the Either a a type 

On Thu, Sep 17, 2020 at 3:45 AM Oliver Charles <[hidden email]> wrote:
Regardless of having a more abstract version, I'm +1 on Jon's suggestion, and those names. fromEither is something I have reached for many many times and been surprised it's not within arms reach.

On Thu, 17 Sep 2020, at 7:16 AM, Jon Purdy wrote:
I’m strongly for these:

Data.Tuple.dup :: a → (a, a)

Data.Either.fromEither :: Either a a → a

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

Re: Diagonalization/ dupe for monads and tuples?

Oliver Charles-3
You may wish to compare with fromMaybe then, which probably also doesn't have the type you'd expect :) The type you have there is more like bifoldMap

On Thu, 17 Sep 2020, at 1:42 PM, Carter Schonwald wrote:
I’d expect fromEither to be 
Either a b -> (a-> c )-> (b-> c) -> c 

Nothing about the name fromEither is suggestive of the Either a a type 

On Thu, Sep 17, 2020 at 3:45 AM Oliver Charles <[hidden email]> wrote:

Regardless of having a more abstract version, I'm +1 on Jon's suggestion, and those names. fromEither is something I have reached for many many times and been surprised it's not within arms reach.

On Thu, 17 Sep 2020, at 7:16 AM, Jon Purdy wrote:
I’m strongly for these:

Data.Tuple.dup :: a → (a, a)

Data.Either.fromEither :: Either a a → a


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

Re: Diagonalization/ dupe for monads and tuples?

chessai .
My instinct about fromEither's type was the same as Carter's, and I had to remind myself of fromMaybe. I like the name fromEither overall. Seems to fit well with precedent and is straightforward enough.

On Thu, Sep 17, 2020, 07:45 Oliver Charles <[hidden email]> wrote:
You may wish to compare with fromMaybe then, which probably also doesn't have the type you'd expect :) The type you have there is more like bifoldMap

On Thu, 17 Sep 2020, at 1:42 PM, Carter Schonwald wrote:
I’d expect fromEither to be 
Either a b -> (a-> c )-> (b-> c) -> c 

Nothing about the name fromEither is suggestive of the Either a a type 

On Thu, Sep 17, 2020 at 3:45 AM Oliver Charles <[hidden email]> wrote:

Regardless of having a more abstract version, I'm +1 on Jon's suggestion, and those names. fromEither is something I have reached for many many times and been surprised it's not within arms reach.

On Thu, 17 Sep 2020, at 7:16 AM, Jon Purdy wrote:
I’m strongly for these:

Data.Tuple.dup :: a → (a, a)

Data.Either.fromEither :: Either a a → a

_______________________________________________
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: Diagonalization/ dupe for monads and tuples?

Carter Schonwald
I’m not sure how fromMaybe relates here.  Could someone explain?

For the anti-categorical folks who dislike codiag or related names like trace (in linear algebra trace is the sum of the diagonal of a matrix as a scalar, an apt analogy I think), another name that I think is descriptive is collapse 


Names bandied about so far: 

Dedup 
Codiag
Fromeither 

Things I mentioned above : trace and collapse 

Zooming out though, this operation is equiv to “either id id”, so I don’t really see how inventing a new name for this specific tiny snippet really helps anyone. 


On Thu, Sep 17, 2020 at 8:54 AM chessai <[hidden email]> wrote:
My instinct about fromEither's type was the same as Carter's, and I had to remind myself of fromMaybe. I like the name fromEither overall. Seems to fit well with precedent and is straightforward enough.

On Thu, Sep 17, 2020, 07:45 Oliver Charles <[hidden email]> wrote:
You may wish to compare with fromMaybe then, which probably also doesn't have the type you'd expect :) The type you have there is more like bifoldMap

On Thu, 17 Sep 2020, at 1:42 PM, Carter Schonwald wrote:
I’d expect fromEither to be 
Either a b -> (a-> c )-> (b-> c) -> c 

Nothing about the name fromEither is suggestive of the Either a a type 

On Thu, Sep 17, 2020 at 3:45 AM Oliver Charles <[hidden email]> wrote:

Regardless of having a more abstract version, I'm +1 on Jon's suggestion, and those names. fromEither is something I have reached for many many times and been surprised it's not within arms reach.

On Thu, 17 Sep 2020, at 7:16 AM, Jon Purdy wrote:
I’m strongly for these:

Data.Tuple.dup :: a → (a, a)

Data.Either.fromEither :: Either a a → a

_______________________________________________


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
123