On 20/09/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> 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")]]
Oh, looks like I was way off. So in this particular scenario, when one
side 'runs out' of structure, that part degenerates to a one-side fmap
using the leaf value as the non-hyper arg.
Of course, this is the behaviour for /built-in/ arrays--it's up to the
person defining &fzip to determine how to handle their own Zippable
types. So, if they want &fzip to fail() on incompatible structures, or
do some other crazy thing, they can just put that in their version of
&fzip.
> 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.
Bottom line: user-defined &fzip turns two structures into one
structure of pairs (in whatever way the user deems reasonable), and
then &fmap transforms the tuples of that one structure.
For things like `foo(»$x«, »$y«, »$z«)` (assuming it ends up being
supported), you would either extend &fzip over n-tuples, or just use
pair-fzip repeatedly and reduce the nested pairs into a single
n-tuple.
> Nope. Here it is. And it was 22 lines. :-)
>
> http://svn.luqui.org/svn/misc/luke/work/code/haskell/hyper.hs
Thanks, that made it a lot clearer. Haskell++ :)
I just hope you and I aren't the only ones who think this is a great idea...
Stuart
