Matt Harden wrote:
>
> It has always seemed to me that having multiple zip functions with
> different names (zip, zip3, zip4, etc..) was unfortunate, and a single
> zip that handled all possible tuples would be better. Now, with
> Multi-Parameter Type Classes and Functional Dependencies, we have an
> opportunity to make zip more sensible.
> Note: I am not proposing this as a "typo" for the current report, but
> for a future version of standard Haskell. Obviously, this would only be
> valid if MPTC's and FD's become part of the future standard.
>
> I would propose:
> o zip be renamed to zip2 and zipWith to zipWith2
> o zip be changed to map tuples-of-lists to lists-of-tuples (the
> "opposite" of unzip)
Yes, I've always thought this should be the more sensible type. I know
most Haskellers prefer to always curry, but I tuple in places where it
seems to make sense, like here.
> o A Zippable class be created, defining zip and unzip for all tuple
> types (or at least the first few)
For _all_ tuple types? That's a lot of instance declarations ;-)!
> o (optional) a ZipFunctor class (subclass of Functor) defining a
> function which applies a collection of functions to a collection of
> values giving a collection of results. The list type ([]) would of
> course be a member of this class.
I like this idea. Back before the days of "Functional Dependencies"
I took a stab at trying to do something like this, unsuccessfully.
>
> The advantages I see:
> o zip . unzip === id
> o types of zip & unzip are consistent with each other
> o zip could be extended via the class mechanism to work with
> non-list collections, and non-tuple elements
>
> Disadvantages:
> o Existing code using zip would break
> o Implementation might be less efficient than current zip & unzip
>
> Sample implementation:
> > ...
<shameless plug>
I have a paper ("The Zip Calculus", MPC 2000) which is a bit more
ambitious, and is correspondingly more complex. My solution allows
one to write the generic zip without use of the class system and
the theoretic need for an infinite number of instance declarations.
It allows you to write transpose
transpose :: ((a,b),(c,d),(e,f)) -> ((a,c,e),(b,d,f))
generically for any m*n "matrix".
I hope to write up a proposal for how to add this capability to Haskell
in the not too distant future.
You can get the paper here if you're interested:
http://cs-www.cs.yale.edu/~tullsen/zip-mpc.ps
<\shameless plug>
- Mark Tullsen
