# Re: Junctions, patterns, and fmap again

```On 9/19/05, Stuart Cook <[EMAIL PROTECTED]> wrote:
> On 19/09/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Part 1: fmap
> >
> > I have a plan for the \$x »+« \$y form (and also foo(»\$x«, »\$y«, »\$z«)),
> > but I don't want to go into that right now.  It basically involves
> > zipping the structures up into tuples and applying the function to the
> > tuples.
>
> Does this mean that 'unary' (one-side) hyper would be
> structure-preserving, but 'binary' (two-side) hyper would not? Or
> would you take the final list of tuples and re-build a structure?```
```
Well, I've written up the details in a 40 line Haskell program to make
sure it worked.  I think I deleted the program, though.

The basic idea is that, alongside Functor, you have a Zippable theory
which defines:

theory Zippable[::T] {
multi zip (T[::A], T[::B] --> T[:(::A, ::B)]) {...}
}

Where that last coloney madness is a yet-to-be-proposed tuple type
(but tuples can be emulated if they are not in the core language, so
it's no biggie).  That is, zip takes two structures and figures out
how to combine them in a reasonable way into pairs of values.  So:

zip([1,2,[3,4]], [["a","b"], "c", "d"])

Gives:

[[:(1,"a"), :(1,"b")], :(2,"c"), [:(3,"d"), :(4,"d")]]

In order to be consistent with the specced semantics.  In order to
keep with the specced semantics of junctions, you'll probably see:

zip(1|2, 3&4)

Give:

(:(1,3) & :(1,4)) | (:(2,3) & :(2,4))

So it's really up to the zippable functor itself to figure out the
best way to zip.  After the structures are zipped up, you fmap the
binary function on each of the tuples, resulting in a reasonable
functor structure again.

Hmmm, that should probably be fzip or something.

Luke
```