Add combine :: Adjunction f u => u a -> f b -> (a, b)

[sjoerdvisscher]

When playing with a bit of code I needed a combine function, which I think should be part of the adjunctions library.

combine :: Adjunction f u => u a -> f b -> (a, b) combine ua = rightAdjunct (\b -> fmap (\a -> (a, b)) ua)

https://gist.github.com/1621224

greetings, Sjoerd Visscher

[ekmett]

I actually used to have a notion of that called 'zap'. Apparently I let it go somewhere along the way.

http://hackage.haskell.org/packages/archive/adjunctions/0.5.1/doc/html/Data-Functor-Zap.html

I'll happily throw it in when I get a minute -- I'm a bit harried getting ready for Hac Boston this week.

-Edward

On Mon, Jan 16, 2012 at 10:03 AM, Sjoerd Visscher < reply@reply.github.com

wrote:

When playing with a bit of code I needed a combine function, which I think should be part of the adjunctions library.

combine :: Adjunction f u => u a -> f b -> (a, b) combine ua = rightAdjunct (\b -> fmap (\a -> (a, b)) ua)

https://gist.github.com/1621224

greetings, Sjoerd Visscher

---

Reply to this email directly or view it on GitHub: https://github.com/ekmett/adjunctions/issues/1

[sjoerdvisscher]

Nice, zapWith is even better. (I don't know about the newtype.)

But take your time, it was just a bit of toy code, and I don't think it adds anything useful to the enumerator/conduit/pipe discussion.

[ekmett]

The problem is that compositions of 'zappable' things form a zappable thing, which leads to 4 ways to stick together adjunctions, so you can't just hide the idea in a class if you want it to be truly general, as the fundeps don't have a canonical way to go.

F |- G H |- I

you can use the F to navigate the G, and the H to navigate the I, but you can also swap either of them

FH zaps GI FI zaps GH

and there are things you can 'zap' that aren't given rise to directly by a haskell adjunction, since as long as F uses a sum wherever G uses a product, and you feed the values in one to the functions in the other you can find a functor that 'zaps' basically anything.

I'll be honest, I hate the name and I don't find the concept all that interesting, but I'll probably add the simple adjunction based zap somewhere though.

It also follows from the fact that every Hask -> Hask adjunction is representable by the left adjoint wrapped around unit and that you can extract the contents of the left adjoint (with splitL), and then index with the f () that remains.

I wrote up an article the basic idea a few years ago after Wouter wrote his "data types a la carte" paper.

http://comonad.com/reader/2008/the-cofree-comonad-and-the-expression-problem/

-Edward

On Wed, Jan 18, 2012 at 4:35 AM, Sjoerd Visscher < reply@reply.github.com

wrote:

Nice, zapWith is even better. (I don't know about the newtype.)

But take your time, it was just a bit of toy code, and I don't think it adds anything useful to the enumerator/conduit/pipe discussion.

---

Reply to this email directly or view it on GitHub: https://github.com/ekmett/adjunctions/issues/1#issuecomment-3543109

[sjoerdvisscher]

What about just a type synonym

type Zap f g = forall a b c. (a -> b -> c) -> f a -> g b -> c

zap :: Zap f g -> f (a -> b) -> g a -> b
zap z = z id

flipZap :: Zap f g -> Zap g f 
flipZap z f a b = z (flip f) b a

composeZap :: Zap f g -> Zap h i -> Zap (Compose f h) (Compose g i) 
composeZap u v f (Compose a) (Compose b) = u (v f) a b

[ekmett]

I definitely like that better.

On Thu, Jan 19, 2012 at 2:58 AM, Sjoerd Visscher < reply@reply.github.com

wrote:

What about just a type synonym

type Zap f g = forall a b c. (a -> b -> c) -> f a -> g b -> c

zap :: Zap f g -> f (a -> b) -> g a -> b
zap z = z id

flipZap :: Zap f g -> Zap g f
flipZap z f a b = z (flip f) b a

composeZap :: Zap f g -> Zap h i -> Zap (Compose f h) (Compose g i)
composeZap u v f (Compose a) (Compose b) = u (v f) a b

---

Reply to this email directly or view it on GitHub: https://github.com/ekmett/adjunctions/issues/1#issuecomment-3559262