8 Dec 2012 16:27

## Variable-arity zipWith (re)invented.

```Continued discussion from

Thank you for all the answeres and thinkings;

Here's zipWithN for general Zip functors: [1] . This, together with
[2] may constitute a small hackage. A modification from Wren's idea to
[1] is the use of fmap instead of repeat.

I'm wondering if there are any laws for Zip functors. I first thought
that there are similarity between Zips and Applicatives, as [3] states

>    instance Applicative f => Zip f where
>        zip = liftA2 (,)

However, my intuition is that zipping two arrays should result in an
array of size of the same order as two, giving rise to a Zip functor
law candidate:

zipWith const xs \$ zipWith const xs ys == zipWith const xs ys

which is violated by the above statement "zip = liftA2 (,)" .

[1] https://github.com/nushio3/practice/blob/master/variable-arity/ZipWithN-2.hs
[2] https://github.com/nushio3/practice/blob/master/free-objects/zipf-12.hs

--
```

10 Dec 2012 23:57

### Re: Variable-arity zipWith (re)invented.

```On Sat, Dec 8, 2012 at 10:27 AM, Takayuki Muranushi <muranushi <at> gmail.com> wrote:
> Continued discussion from
>
>
> Thank you for all the answeres and thinkings;
>
>
> Here's zipWithN for general Zip functors: [1] . This, together with
> [2] may constitute a small hackage. A modification from Wren's idea to
> [1] is the use of fmap instead of repeat.
>
> I'm wondering if there are any laws for Zip functors. I first thought
> that there are similarity between Zips and Applicatives, as [3] states
>
>>    instance Applicative f => Zip f where
>>        zip = liftA2 (,)
>
> However, my intuition is that zipping two arrays should result in an
> array of size of the same order as two, giving rise to a Zip functor
> law candidate:
>
> zipWith const xs \$ zipWith const xs ys == zipWith const xs ys
>
> which is violated by the above statement "zip = liftA2 (,)" .
>
>
>
>
```

11 Dec 2012 01:23

### Re: Variable-arity zipWith (re)invented.

```Repeated thanks to you, Adam! Your code is brilliantly simple.

(7.6.1)  .....
Can we guess why? The version of packages we are using?

Mines are here.

>>>  :t forZ [1,2,3] (+)
forZ [1,2,3] (+)
:: (Num t, Num a, TypeCast br HFalse,
HBuild2' br (HCons [t] HNil) (a -> a -> a) r) =>
r
>>>  forZ [1,2,3] [10] (+)

<interactive>:13:1:
Couldn't match type `[y]' with `(a0 -> a0 -> a0) -> t0'
When using functional dependencies to combine
Apply ApplyZap (a, b) [y],
arising from the dependency `f a -> r'
in the instance declaration at Part1.lhs:193:12
Apply ApplyZap ([[t2]], [t1]) ((a0 -> a0 -> a0) -> t0),
arising from a use of `forZ' at <interactive>:13:1-4
In the expression: forZ [1, 2, 3] [10] (+)
In an equation for `it': it = forZ [1, 2, 3] [10] (+)
>>> forZ [1,2,3] "hi there" (,)

<interactive>:14:1:
```

11 Dec 2012 16:25

### Re: Variable-arity zipWith (re)invented.

```On Mon, Dec 10, 2012 at 7:23 PM, Takayuki Muranushi <muranushi <at> gmail.com> wrote:
>
> (7.6.1)  .....
> Can we guess why? The version of packages we are using?
>
> Mines are here.
>
>
>
>>>>  :t forZ [1,2,3] (+)
> forZ [1,2,3] (+)
>   :: (Num t, Num a, TypeCast br HFalse,
>       HBuild2' br (HCons [t] HNil) (a -> a -> a) r) =>
>      r
>>>>  forZ [1,2,3] [10] (+)
>
> <interactive>:13:1:
>     Couldn't match type `[y]' with `(a0 -> a0 -> a0) -> t0'
>     When using functional dependencies to combine
>       Apply ApplyZap (a, b) [y],
>         arising from the dependency `f a -> r'
>         in the instance declaration at Part1.lhs:193:12
>       Apply ApplyZap ([[t2]], [t1]) ((a0 -> a0 -> a0) -> t0),
>         arising from a use of `forZ' at <interactive>:13:1-4
>     In the expression: forZ [1, 2, 3] [10] (+)
>     In an equation for `it': it = forZ [1, 2, 3] [10] (+)
>>>> forZ [1,2,3] "hi there" (,)
```

11 Dec 2012 09:14

### Re: Variable-arity zipWith (re)invented.

Hi Takayuki,

Just thought I'd mention another approach to a variadic zipWith, this one using type families:

http://typesandkinds.wordpress.com/2012/11/26/variable-arity-zipwith/

The current lack of overlap in type families makes things a bit more complicated, but it can
be solved using the upcoming overlapping type families.

Cheers,
Pedro

On Sat, Dec 8, 2012 at 3:27 PM, Takayuki Muranushi wrote:
Continued discussion from

Thank you for all the answeres and thinkings;

Here's zipWithN for general Zip functors: [1] . This, together with
[2] may constitute a small hackage. A modification from Wren's idea to
[1] is the use of fmap instead of repeat.

I'm wondering if there are any laws for Zip functors. I first thought
that there are similarity between Zips and Applicatives, as [3] states

>    instance Applicative f => Zip f where
>        zip = liftA2 (,)

However, my intuition is that zipping two arrays should result in an
array of size of the same order as two, giving rise to a Zip functor
law candidate:

zipWith const xs \$ zipWith const xs ys == zipWith const xs ys

which is violated by the above statement "zip = liftA2 (,)" .

[1] https://github.com/nushio3/practice/blob/master/variable-arity/ZipWithN-2.hs
[2] https://github.com/nushio3/practice/blob/master/free-objects/zipf-12.hs

--
Takayuki MURANUSHI
The Hakubi Center for Advanced Research, Kyoto University
http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

_______________________________________________
```_______________________________________________