A little off-topic i know but ...
Has anyone ever thought of trying to use reflection in these cases.
i.e. still declare the instance but have a common method which
examines the arguments and dynamiclly constructs the result depending
(dynamically) on the type of the argument.
I have never thought about using thius for zip but have for
things like read / show.
i.e. rather than having a read / show method for each type
we have a generic one which "asks" the type which type it
actually is or requests a constructor by name.
> -----Original Message-----
> From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED]]
> Sent: 21 July 2000 17:29
> To: 'Mark Tullsen'; Matt Harden
> Cc: [EMAIL PROTECTED]
> Subject: RE: The type of zip
>
>
> | > No doubt. But seriously, I was thinking of a "built-in" Zippable
> | > instance just like we have for Ord, Enum, Show, etc.
> |
> | That's what I thought you meant. But since I have a pet peeve about
> | how Haskell implementations work ...
>
> Is your peeve related to the built-in "deriving" mechanism?
> I agree! You might like to look at the paper Ralf Hinze and I
> have submitted to the Haskell Workshop
> http://research.microsoft.com/~simonpj/#derive
>
> It doesn't give a way to have a proper infinite family of tuples, but
> it does make generic programming easier.
>
> | > > 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.
>
> That certainly sounds interesting.
>
> Simon
>
