Re: ANNOUNCEMENT: hMPI [HaskellMPI] 0.9.0 available

[Benjamin Leon Russell]

Do you have any plans on making a Windows 9x/NT/2000-compatible version anytime soon?

On Fri, 21 Jul 2000 01:07:21 +0200
 [EMAIL PROTECTED] (Michael Weber) wrote:
> [Xposted to ghc-users & haskell mailing lists]
> 
> [stuff deleted]
> 
> -- Prerequesites 
> 
> Architecture: i386-linux, sun-sparc-solaris2

--Benjamin L. Russell
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: The type of zip

[Marcin 'Qrczak' Kowalczyk]

Thu, 20 Jul 2000 15:59:36 -0500, Matt Harden <[EMAIL PROTECTED]> pisze:

> I was thinking of a "built-in" Zippable instance just like we have
> for Ord, Enum, Show, etc.

What about zipWith, curry, uncurry, liftM, zipWithM?

Also I was not able to unify callN series from
 (QForeign.hs).

Is it possible to have some clever classes with instances for tuples
that would make some kinds of operations definable for all tuples
at once?

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/GCS/M d- s+:-- a23 C+++$ UL++>$ P+++ L++>$ E-
  ^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: The type of zip

[Mark Tullsen]

Matt Harden wrote:
> 
> Mark Tullsen wrote:
> > Matt Harden wrote:
> > >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 ;-)!
> 
> 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 ...

> I think the
> language definition specifies these instances for all tuple types that
> have sensible instances of these classes. 

Yes, AFAIK the Report doesn't say anything about implementations being
allowed to not support "deriving" for 6-tuples or 8-tuples or whatever.

> Actual Haskell
> implementations don't provide these instances for all tuples, AFAIK.

Yes, ugh.  I just tested hugs and ghc: they stop at 5-tuples.

Someone can correct me if I'm wrong, but the problem appears to
arise because tuples are not "really" first class in Haskell.
They are just syntactic sugar for fully applied uses of the 
following constructors:
  (,) 
  (,,)
  (,,,)
  ...
Which seems to be the reason why tuples are lifted in Haskell.
(Or they are lifted for other reasons, and thus this implementation
then makes sense.)

> 
> > 
> >
> > 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
> 
> I have lots of questions, but I'll wait until I've read your paper.

The paper is a little heavy going with all this Pure Type System
stuff.  In case it's helpful, I put a copy of the slides from my
MPC talk on the web:
  http://cs-www.cs.yale.edu/~tullsen/zip-mpc-talk.ps

- Mark

Re: The type of zip

[Matt Harden]

Mark Tullsen wrote:
> Matt Harden wrote:
> >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 ;-)!

No doubt.  But seriously, I was thinking of a "built-in" Zippable
instance just like we have for Ord, Enum, Show, etc.  I think the
language definition specifies these instances for all tuple types that
have sensible instances of these classes.  Actual Haskell
implementations don't provide these instances for all tuples, AFAIK.

> 
> 
> 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

I have lots of questions, but I'll wait until I've read your paper.

Thanks!
Matt Harden

Re: The type of zip

[Mark Tullsen]

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:
> > ...



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