new Library Infrastructure spec.

[Isaac Jones]

"S. Alexander Jacobson" <haskell at alexjacobson.com> writes:

> Perhaps it makes sense to define the mission more
> precisely.  The document begins:
>
>   The Haskell Library Infrastructure Project is an
>   effort to provide a framework for developers to
>   more effectively contribute their software to the
>   Haskell community.

Software includes Haskell libraries and other tools writen in Haskell.

> Does "software" include an IDE written in C, Python, or Java?

No.

> Does it include GHC itself? Are we really trying to design a Haskell
> wrapper around autoconf, make, or Installshield?  Why reinvent the
> wheel?

What do you mean?  I don't think we ever claimed to be trying to
implement autoconf or installshield.  There are certain kinds of
packages for which we think using make won't be necessary.  Likewise,
autoconf is overkill for certain kinds of packages.

Wrapping autoconf is not the same as reinventing autoconf.

> Given that this document is part of "Library
> Infrastructure", perhaps it makes sense to
> restrict the mission to:

We're going to rename the "Library Infrastructure Project" to reflect
that it is for other tools written in Haskell as well.  The idea that
it is for libraries only keeps creeping in and I keep pusing it back,
but I'm not always as firm as I should be.  We really need to rename
it.

>   The Haskell Library Infrastructure Project is an effort to provide
>   a framework that makes it easy for Haskell developers to package
>   *haskell libraries* for easy installation into any Haskell
>   development environment.

I don't think we should restrict it to Haskell libraries only.  I
still don't see any real gain in doing so.

> Following this more restricted mission, the HPS
> would be something that autoconf calls to interact
> with the local Haskell environment rather than
> vice-versa.

It can work both ways.  The Setup.lhs script can call autoconf, which
can query the package database, for instance.

> Perhaps it makes sense to work through some actual
> real life examples.  If I have a package that
> combines C, Perl, and Haskell?  How should I
> distribute install it?  HPS or Autoconf?


HPS can wrap autoconf in this case.  It doesn't have to, though.  You
could implement whatever you need directly in the Setup script.


peace,

  isaac