Summary of progress

Ian Lynagh igloo@earth.li
Sun, 11 Mar 2001 23:39:05 +0000


On Sun, Mar 11, 2001 at 01:28:38PM +0000, Malcolm Wallace wrote:
> 
> Proposal 2b: adopt a "Std." namespace for libraries that
>              are common to all implementations.
> 
>   * There is little agreement here.  Simon M, Manuel, and
>     others have expressed their doubts that it is workable.
>     No-one has defended the idea except me.  But then Simon
>     posted a hierarchy layout proposal in which "Haskell."
>     seemed to take the role of "Std.".  So I'm a bit
>     confused.  I'd like to see some more discussion about
>     this.

I think that a common prefix for the standard libraries will get to be
a pain far more than one for non standard ones, and non standard ones
are going to have a huge prefix for uniqueness anyway. The chances are
most modules will either be in . or be standard anyway. My vote is for
a user.* hierarchy with mangled e-mail addresses as I have previously
described.

> Proposal 3: develop a social process for adding new libraries
>             to the "standard" set.
> 
>   * Well, this list is the starting point, so there's not
>     much more to be said on that.
>   * The set of criteria by which we as a community might
>     judge whether a library is recognised as "standard"
>     have not really received any comment.

In the absence of some sort of committee or community voting, it
essentially comes down to what the hugs, GHC and NHC maintainers agree
on in practise. As things stand I suspect it will be decided between
then with the more controversial ones argued out on a mailing list.

> Other issues:
> 
>   * We have mentioned briefly that "standard" libraries
>     should be available in all Haskell systems.  But Manuel
>     pointed out that many libraries will be developed
>     independently of particular compilers - and so they
>     should be distributed separately, to ensure they remain
>     up-to-date with external software (e.g. C libraries).
>     I think we need to think carefully about how to manage
>     this process.  A single repository of compiler-independent
>     and build-system-independent library code would be a
>     good start.  But it won't be sufficient.

I am unclear on precisely what the problem is here. Clearly the
language extension libraries (like IO) will be implementation specific
and will be maintained with the implementation. For those implementable
in pure Haskell there should be a page, probably on haskell.org, which
links to all the known implementations of each library and each
implementation would then take the latest stable release when it wanted
to release of the implementation it chose, or had one of it's own that
made use of it's own specific extensions. For the purposes of not losing
things when sites disappear, and if haskell.org can cope with this, it
may be sensible to have copies on haskell.org somewhat akin to cpan.org.


This is as good a time as any to bring up testsuites. I propose that,
as part of the interface that defines a library, there must be a
testsuite that uses only existing standard libraries, Haskell 98 and the
new library and checks anything the designer can think of that the
library might do wrong.


Thanks
Ian
-- 
Ian Lynagh - <igloo@earth.li>
http://c93.keble.ox.ac.uk/~ian/haskell/