Re: The type of zip

[Claus Reinke]

Lennart Augustsson:
> > If you are happy with the isomorphism
> >
> > (T1 x T2 x ...) <-> (T1 x (T2 x (...)))
> 
> But in Haskell these are not isomorphic.
> (a,b,c) is NOT isomorphic to (a,(b,c)), just think about bottom.

Right, thanks. I should have been more precise. On the right, "the"
product is built step-by-step, and each step could fail, whereas
on the left, "the" product is built in one step, taking all components
at once - only one chance to fail (I'm always tempted to think of
bottom at type T as failure to terminate inside T, counting bottom 
at T as outside the part of T I'm interested in instead of counting
it as a part of T proper..). In other, words, Haskell treats a product
of a type "a" with a product of a type "b" with a type "c" as 
different from a product of three types "a", "b", and "c". Have I 
missed anything else so far?


My point was that, in Haskell, instead of a single family of 
n-products for each n (indexed by component types) that is built 
from smaller products, we have the odd situation that there is one
family of n-products for each n, not built from smaller products, 
plus a variety of ways to build structures with n components from 
smaller products, all distinguished by their types (due to the 
non-associative and multiple-arity constructors, the type records 
the order in which a given product structure was built up, e.g., 
(a,((b,a,b),a)) is different from (a,b,a,b,a) and so on..).

This can be quite useful in a dynamically typed language, where
such nested tuple-structures can serve as anonymous data-structures,
but in a statically typed language it is often difficult to operate on
these nests (hence this thread), and we have other ways to build
nested data-structures. So it might (or might not - that's what I'm
trying to find out) be useful to make product (de-)construction
associative (or to provide an associative alternative).


Matt has outlined a not-so-drastic variant, because we both seem
to shy away from the full implications of such a step. Such an 
intermediate solution might be more appropriate for Haskell.

Still, I would like to know whether a drastic approach (associative 
product with some constraint to guarantee unique decomposition 
in pattern matches) could be made to work and what the result 
would look like. In contrast to Matt's assumption that (a), for 
some expression a, "would of course not be considered a tuple", 
I think that all expressions would be (approximations of) tuples,
either explicitly as 0-tuple () or (n+2)-tuple (a,b), or implicitly as
1-tuple (a), if a is not itself of 0- or (n+2)-tuple type (all things
would be products, just the number of components would differ).

Other "oddities" of an associative ',': 

- one would think that () simply takes its role as a unit, so that 
  (),a == a == a,()
  but  if we know x::()  does that imply that x,a == a ?
  x could be bottom, and the equations for the unit look strict in their
  unit parameter, so probably not;
- despite this first point, n-products might not need to be strict
   in their components, only in their structure, whatever that
   means exactly..
- (let (a,b) = (1,2,3) in (a,b)) == (1,2,3)
  but there are many ways to bind a and b to parts of (1,2,3)
- other surprises?

Yet these are merely unusual (at least I am not used to think
this way about Haskell products), e.g., a type annotation would
suffice to resolve the matching ambiguity and in practice the
types will often be determined by the usage context if the result 
of the match is used at all. The strictness properties seem slightly
more puzzling, but perhaps I'm just not looking at the problem
the right way?

So I would like to know: are there any programming languages
with associative products, and is there any real point against
this feature (beyond "unusual")?

In case you don't just like the puzzle for the puzzle's sake, there
are two practical motivations for this:

- the current "products" in Haskell are a pain
- extensible records in TREX use associative commutative
  construction and matching, but built-in for one specific
  construct (rows); it would be nice if these properties of
  constructors could be supported more generally, and 
  extensible records be built on top of such general support

Just curious,
Claus

Re: Haskell libraries, support status, and range of applicability(was:Haskell jobs)

[Olaf Chitil]

> I have never submitted any request to the maintainers
> of www.haskell.org to place links to my modules. Yet,
> several of them are there, and that tells me that either John
> or Olaf does occasional scan of messages from this
> list and update the pages from time to time. 

The latter is exactly what I do and how 99% of the information about
tools and libraries were collected. The main page of haskell.org asks
for information about projects, compilers, papers, classes, or anything
else but we hardly receive any. This is why I am rather wary about
putting much effort into any automatic submission and updating scheme
(maybe I should put a simple form there which just forwards any
information to John and me via email? ;-). And if you want to know if a
library is still supported/further developed, then just click on the
link and look at the web page for the library. If it talks about Haskell
1.2 and plans for 1995 you know what (not) to expect.

Unfortunately many libraries and tools do not even have proper web pages
to link to from haskell.org (Michal Weber, are you listening? ;-).
Simon, can you tell me how I shall link to hslibs, especially each
individual library? Obviously a user would also like to download a
single library. Are the URLs stable?

I do not want to sound too negative. I am always happy about suggestions
for improving haskell.org (especially if they do not imply too much work
;-). And I completely agree that supported libraries should somehow be
more visible.

I didn't update haskell.org for a few month because I had to finish my
thesis, move to York and start a new project here. But I will update the
pages with all the stuff that accumulated in the meantime very soon.

Cheers,
Olaf

-- 
OLAF CHITIL, 
 Dept. of Computer Science, University of York, York YO10 5DD, UK. 
 URL: http://www.cs.york.ac.uk/~olaf/
 Tel: +44 1904 434756; Fax: +44 1904 432767

Re: Precision problem

[Fergus Henderson]

On 25-Jul-2000, Julian Assange <[EMAIL PROTECTED]> wrote:
> Fergus Henderson <[EMAIL PROTECTED]> writes:
> 
> > Jon Fairbairn was talking about Haskell.  MSVC is a C/C++ compiler,
> > not a Haskell compiler.  For C and C++, there are many many areas of
> > undefined, unspecified, or implementation-defined behaviour.  If a
> > C or C++ program gives different behaviour on different runs or with
> > different compilation flags, this is almost always due to the program
> > depending on one of those areas, rather than due to the compiler not
> > conforming to the standard.
> 
> Standard, shmandard. If a compiler can't produce reproducable code,
> then its of little value for scientific computing.

*If* you write C code which strict conforms to the standard, then any
conforming compiler will give you reproducible results.
The only times that you will not get reproducible results is if
you either accidentally or deliberately write code which is not
strictly conforming, if you invoke the compiler in a
non-standard-conforming mode, or if there is a compiler bug.

Writing strictly conforming C code is difficult.  Very difficult.
If you want reproducible results, and you don't know how to write
strictly conforming C code, then don't use C!  There are plenty of
languages which make it much easier to get reproducible results.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW:   |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.

Re: The type of zip

[Marcin 'Qrczak' Kowalczyk]

25 Jul 2000 08:56:09 GMT, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> pisze:

> Ah, I was once doing such overloading of IO functions. I tried but
> was not able to adapt it to "threaded" foreign calls.

Help! Now it looks easier, but still I can't get it.

Assume we have:

class Arg f h where
arg :: (f -> IO a) -> h -> IO a

I want to unify the following functions:

call0:: IO a -> IO a
call0 = id

call1:: Arg f1 h1 => (f1 -> IO a) -> h1 -> IO a
call1 = arg

call2:: (Arg f1 h1, Arg f2 h2)
  => (f1 -> f2 -> IO a) -> h1 -> h2 -> IO a
call2 f h1 h2 = arg (\f1 -> call1 (f f1) h2) h1

call3:: (Arg f1 h1, Arg f2 h2, Arg f3 h3)
  => (f1 -> f2 -> f3 -> IO a) -> h1 -> h2 -> h3 -> IO a
call3 f h1 h2 h3 = arg (\f1 -> call2 (f f1) h2 h3) h1

call4:: (Arg f1 h1, Arg f2 h2, Arg f3 h3, Arg f4 h4)
  => (f1 -> f2 -> f3 -> f4 -> IO a) -> h1 -> h2 -> h3 -> h4 -> IO a
call4 f h1 h2 h3 h4 = arg (\f1 -> call3 (f f1) h2 h3 h4) h1

...

Conversion of the return value will be later, now only these.
I want to produce something like
call :: Call f h => f -> h
instance Call (IO a) (IO a)
instance (Arg fa ha, Call ff hf) => Call (fa -> ff) (ha -> hf)

I don't have an idea which functions to put in a class to tie the
recursion! The problem is that arg needs IO just here, and in a
class IO is hidden deep inside the function type.

Maybe some additional type parameters with functional
dependencies could help here. I've already done a similar case,
, but that was easier.

-- 
 __("<  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: Haskell libraries, support status, and range of applicability(was:Haskell jobs)

[Jan Skibinski]

On Mon, 24 Jul 2000, Claus Reinke wrote:

> Jan Skibinski:
> > On Wed, 19 Jul 2000, Claus Reinke wrote:
> > 
> > [List of some examples of library status information..] 
> > 

> Someone asks about GUIs on comp.lang.functional, on the 
> Haskell list, or elsewhere, and we just point them towards the
> library list at haskell.org - question answered, problem solved,
> isn't Haskell just nice?-) 

True.

> Seeing a last-contact date for a library tells me more: on that
> date, the authors' plans where these. 

I always put two dates on my pages for the exact same reason,
which you are raising. But doing it on my own web is one
thing, and putting extra burden on shoulders of John Peterson
and Olaf Chitil is quite another. I would suggest to take
the example from xxx.laml.gov and formalize submission
process via form interface. As you might have noticed,
the LANL e-print server does not accept free-form
abstracts, because that used to lead to a mess -- including
misspellings of the very word 'abstract'.
 
I have never submitted any request to the maintainers
of www.haskell.org to place links to my modules. Yet,
several of them are there, and that tells me that either John
or Olaf does occasional scan of messages from this
list and update the pages from time to time. It is
quite a burden to keep everything up to date. The
automatic submission process should solve several
things:

+ Put up-to-date status information on the www.haskell.org.
+ Ease the maintenance process of those pages.

For those who do not know how it works on LANL server:
+ You register yourself as an author and receive
  password for any future submission of your articles.
+ During submission of a particular paper your receive
  another password, which relates to that paper only.
  Based on this you have a power to correct your paper
  or even withdraw it.
 
> I think that would be a good idea for Haskell (but please,
> not at the level of comma positions;-).

I used to be bitching about that too:-). But
I later realized that those little things are also
really important for readability of the software.

> 
> Perhaps haskell.org could give out reference numbers for 
> software? So instead of the haskell.org maintainers searching
> high and low for existing software, library authors would actually
> submit their stuff to get a reference number, so that they and
> their users could refer to the software as published on haskell.org
> as [HS-LIB-2000-01] or [HS-TOOL-2000-02] or whatever?

LANL classification system is simple:

quant-ph/0007059 means: Section Quantum Physics, year 00,
(2000), month 07, article number 59 received in that month.
> 
> Once we have references to software (not only to nice publication
> talking about software), the next step could be some form of
> software review, perhaps itself published online as 
> "haskell.org - quarterly software review"?

I second both of your proposals. Alternatively some
sort of reader driven scoring system could be worthwhile to
consider - with a power given to authors to withdraw
their submissions. Such mechanism exists on LANL server.
This is fair to authors.

I think, a number of libraries on Haskell pages reached
some critical mass and it is about time to think of
quality rather than of manifestation of quantity of Haskell
applications.

Jan

Re: Haskell libraries, support status, and range of applicability (was: Haskell jobs)

[Marcin 'Qrczak' Kowalczyk]

Tue, 25 Jul 2000 01:54:46 -0700, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:

> The current implementations predate the Haskell FFI, and so are
> more GHC-specific than they should be, a situation that we hope to
> improve, incrementally.  (Any offers of help?)

There is no consensus for a higher level FFI library.

I would like to help with bringing libraries like Posix (or better
Single UNIX Specification because Posix is not freely available)
to use a "standard" FFI. But:

* I disagree with a few interface decisions, but certainly don't want
  to force my view against others or unnecessarily break compatibility.

* There is no consensus for a higher level FFI library. Again I have
  my own evolving proposal, but it's not something that has been
  agreed to use.

-- 
 __("<  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

[Marcin 'Qrczak' Kowalczyk]

Tue, 25 Jul 2000 10:16:24 +0100, Chris Angus <[EMAIL PROTECTED]> pisze:

> eg. readDyn could have the signature
> 
> String -> Dynamic

It's not possible. Which types are "registered" to be read that way?
What if types have conflicting printed representations?

> around this area I'd be more interested in requesting values by
> name/type rather than discovering the type of an "untyped" object.

Name in which namespace? What if several modules export values and
types of the same name? What if the implementation introduces the
concept of a package, allowing reusing a module name in different
packages?

Those dynamic interfaces assume that there exists a database of all
possible types. But I treat types as a potentially infinite family,
without concrete names. Names are for writing source code, they are
subject to lexical scoping and don't exist at runtime. Each new type
is unique. The compiler statically checks which types are the same,
but it does not allow enumerating all types. Also private types used in
a module are not visible anywhere else, unless the module exports them.

I accept hacks to get constructor names for convenient generation of
Read and Show instances, or Dynamic which allows to temporarily put
a value in a fixed type and then take it back. But both are hacks,
they exist only because they are convenient and we don't know better
solutions - they are *not* elegant, they don't fit the spirit of a
statically typed language with lexical scoping.

Names are context dependent. Objects themselves nor their types don't
have names. The source uses some names to refer to objects from a
particular place, but there exists neither a universal mapping from
names to objects nor a universal mapping in the opposite direction.
Renaming in import lists no longer exists, but it shows that names
are arbitrary and local.

-- 
 __("<  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

[Marcin 'Qrczak' Kowalczyk]

25 Jul 2000 08:56:09 GMT, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> pisze:

> > and why do you pass what seem to be conversion functions as
> > parameters, do they not follow from the types?),
> 
> Not always, e.g. char * may be in, out, or in/out parameter.
> It will get hairy with Unicode.
> 
> But maybe the combination of original and marshalled type, together
> with more explicit treatment of out parameters, would allow convenient
> overloading. I must try, fortunately types are usually explicit.

As I am thinking about it, it could make sense.

There was a problem that passing [a] to a foreign function expecting
Ptr [a] (Ptr is a newtyped Addr), where a is any Storable type,
can be done in several ways. Generally this might be simply an
array with length explicitly passed somewhere else, but strings are
'\0'-terminated and some arrays of pointers are NULL-terminated.

This can be solved by providing more types. Instead of using Ptr String
as a type of a foreign parameter, a newtype CString or the like can
express that it should be '\0'-terminated.

A problem is that there cannot exist both
instance ForeignArg A b
instance ForeignArg a B
because they are overlapping. It means that all instances must use a
concrete top level type constructor in the first type. Or the second.

The foreign type looks more appropriate for being fixed, because
instance Integral a => ForeignArg a Int32
(where the first type is for Haskell and the second is foreign) makes
more sense than the opposite: the set of foreign types is more limited.
It still requires explicit mentioning of all foreign types and their
supported newtypes, but maybe it's not that bad. It excludes
instance ForeignArg Bool Int32
We can live with it.

Out parameters would require explicit allocation of a memory and
passing the raw pointer, thanks to
instance ForeignArg (Ptr a) (Ptr a)
Fortunately
instance Storable a => ForeignArg a (Ptr a)
is not considered overlapping with the former, so passing structures
by pointer would be supported. Oops, but
instance Storable a => ForeignArg [a] (Ptr [a])
is overlapping, so I have to throw away the idea that Ptr [a]
expresses a pointer to an array of a :-(  It must be
instance Storable a => ForeignArg [a] (Ptr a)

I'll try to use these ideas, but I'm afraid that overlapping instances
will bite from time to time.

-- 
 __("<  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

[Chris Angus]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 25 July 2000 09:30
> To: [EMAIL PROTECTED]
> Subject: Re: The type of zip
> 
> 
> Mon, 24 Jul 2000 09:04:58 +0100, Chris Angus 
> <[EMAIL PROTECTED]> pisze:
> 

I dont agree. To me it seems simply like a logical extension of GHC/Hugs'
Dynamic Type.

We maybe couldnt get thye kind of reflection that (say) java has but we
could get some 
useful stuff.

eg. readDyn could have the signature

String -> Dynamic
we can ask the Dynamic what type it is, request a function which does a job
for that type
and invoke the function we are now back in the world of static typing.
around this area I'd be more interested in requesting values by name/type
rather than
discovering the type of an "untyped" object.



> > 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.
> 
> Ugh, IMHO it's bad. Such operations should be overridable for
> particular classes. It breaks abstract types. It throws away static
> check that a type can be shown. It forces to have runtime type
> information for all objects. It requires special cases for various
> primitive types like arrays. It's not compatible with current and
> future extensions to the language (like existential and universal
> quantification).
> 
> I would generally avoid reflection in a statically typed language.
> 
> -- 
>  __("<  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: Precision problem

[Julian Assange]

Fergus Henderson <[EMAIL PROTECTED]> writes:

> Jon Fairbairn was talking about Haskell.  MSVC is a C/C++ compiler,
> not a Haskell compiler.  For C and C++, there are many many areas of
> undefined, unspecified, or implementation-defined behaviour.  If a
> C or C++ program gives different behaviour on different runs or with
> different compilation flags, this is almost always due to the program
> depending on one of those areas, rather than due to the compiler not
> conforming to the standard.

Standard, shmandard. If a compiler can't produce reproducable code,
then its of little value for scientific computing.

Julian.

Re: The type of zip

[Marcin 'Qrczak' Kowalczyk]

Mon, 24 Jul 2000 22:19:36 +0100, Claus Reinke <[EMAIL PROTECTED]> pisze:

> I only had a quick look at QForeign.hs, so I'm not sure whether
> this will help (do you really need that odd chaining of conversion
> functions?

Values of out parameters contribute to the result returned. Parameters
may require freeing some memory after calling the function and
a convenient exception-safe memory allocation and freeing is
(Pointer -> IO a) -> IO a
As compared to separate malloc + free, it should theoretically allow
a more efficient allocator.

> and why do you pass what seem to be conversion functions as
> parameters, do they not follow from the types?),

Not always, e.g. char * may be in, out, or in/out parameter.
It will get hairy with Unicode.

But maybe the combination of original and marshalled type, together
with more explicit treatment of out parameters, would allow convenient
overloading. I must try, fortunately types are usually explicit.

> For instance, if the base case for callN wasn't IO a, the two instance 
> declarations would overlap;

Ah, I was once doing such overloading of IO functions. I tried but
was not able to adapt it to "threaded" foreign calls.

> > 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?
> 
> The problem with tuples is that each length of tuple comes as a separate
> piece of *syntax* in Haskell, not built in a compositional way from tuples 
> of smaller length.

I meant: given the nature of tuples we have, to have clever classes
with instances defined separately for high enough number of tuples,
to use them for various purposes as the only place which has to be
defined for different tuples separately.

Maybe conversion to and from nested pairs would do. But then changing
the nature of tuples themselves would seem more appropriate. With
GHC's -funbox-strict-fields it should be only an advantage.

-- 
 __("<  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

[Marcin 'Qrczak' Kowalczyk]

Tue, 25 Jul 2000 09:02:36 +0200, Lennart Augustsson <[EMAIL PROTECTED]> pisze:

> > If you are happy with the isomorphism
> >
> > (T1 x T2 x ...) <-> (T1 x (T2 x (...)))
> 
> But in Haskell these are not isomorphic.
> (a,b,c) is NOT isomorphic to (a,(b,c)), just think about bottom.

data a :, b = a :, !b

Now (x,y,z) is isomorphic to x:,y:,z:,()

-- 
 __("<  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

[Marcin 'Qrczak' Kowalczyk]

Mon, 24 Jul 2000 09:04:58 +0100, Chris Angus <[EMAIL PROTECTED]> pisze:

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

Ugh, IMHO it's bad. Such operations should be overridable for
particular classes. It breaks abstract types. It throws away static
check that a type can be shown. It forces to have runtime type
information for all objects. It requires special cases for various
primitive types like arrays. It's not compatible with current and
future extensions to the language (like existential and universal
quantification).

I would generally avoid reflection in a statically typed language.

-- 
 __("<  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: Haskell libraries, support status, and range of applicability(was: Haskell jobs)

[Simon Peyton-Jones]

| So generally there is a conflict between making the language better
| and keeping it compatible. Probably indeed the only solution for now
| is to ensure that libraries are being ported to current tools and
| that their state wrt. this process is clearly marked. 

Yes, there is clearly such a conflict.   What not everyone may know, though
is that the Hugs/GHC federation, with much help from others (e.g. Chris
Okasaki)
have been making strenuous efforts to build a set of libraries that work,
are documented, and remain in that happy state.   You'll find the
documentation
at 

http://haskell.org/ghc/docs/latest/set/book-hslibs.html

These libraries are currently rather unromantically called "hslibs".
Better names welcome!

The hslibs libraries come with each release of GHC, and we compile them
with the current GHC every night, so at least they continue to compile.
The better-engineered ones come with a bunch of tests that we run too.
What this means is that at least these libraries should work despite
changing language definition and GHC versions. 

hslibs is not part of GHC, though.   It's intended to be a *Haskell* library

not a *GHC* library. Andy Gill has made a significant fraction of hslibs
work with (STG) Hugs.  The current implementations predate the Haskell FFI,
and so are more GHC-specific than they should be, a situation that we
hope to improve, incrementally.  (Any offers of help?)

hslibs isn't a "closed" library.  Anyone who wants to contribute a library,
and can convince us (not hard!) that it's a Good Library, can get write
permission
to the CVS repository that holds the code.  They contine to "own" and
maintain
their own code.  The Edison library is a good example; it's in the
repository, but
Chris Okasaki maintains it.

hslibs doesn't replace the haskell.org library page.  The latter is very
free-form;
anyone can put anything there, and doesn't have to maintain it.  hslibs has
a bit
of quality control; we try to avoid duplication (one of everything rather
than N of
everything); we don't ship code that no longer works; etc.  I think all this
is a 
step in the direction that various people in this thread have been
advocating.  


Bottom line:

Writing and maintaining good libraries is a lot of work

We need to work together to do this

hslibs is a start in this direction

We would welcome more participation

Simon

Re: The type of zip

[Lennart Augustsson]

> If you are happy with the isomorphism
>
> (T1 x T2 x ...) <-> (T1 x (T2 x (...)))

But in Haskell these are not isomorphic.
(a,b,c) is NOT isomorphic to (a,(b,c)), just think about bottom.

--

-- Lennart