new Library Infrastructure spec.

[S. Alexander Jacobson]

On Fri, 4 Jun 2004, Isaac Jones wrote:
> > Does "software" include an IDE written in C, Python, or Java?
> No.
> Software includes Haskell libraries and other tools writen in Haskell.
>
> >   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.

I don't see any real gain in restricting it only
to libraries and tools written in Haskell.  Given
the flexibility you are trying to achieve
(compilation of arbitrary source, random mucking
around in the local environment, calling
autoconf!), it certainly *looks* like we are
really talking about another generic config tool,
this time written and scripted in Haskell?

Note: It might be perfectly reasonable to write
such a tool to supercede autoconf, just as it was
totally reasonable to write Darc to supercede CVS.
(Though perhaps the community should start
thinking about eating the dogfood).

Aside:  A Haskell tool that calls autoconf will
eventually evolve into a Haskell tool that
replaces autoconf.

The flip side of teh above is that I do see a
substantial gain in having a really simple tool
focused exclusively on installing Haskell
libraries together with their associated data and
binaries into a Haskell development environment
such that they may be easily used from new Haskell
programs.  This gain may include perhaps:

  * an easy way to install Haskell code from autoconf
  * a standard way to access a Haskell interpreter/compiler
  * a safe way to install/run foreign code
  * a much smaller overall project to implement
  * etc..

Perhaps it would be helpful if we walk throug
some scenarios:

Case 1: Suppose I write a package that makes it
easy to call back and forth between Python and
Haskell using some code written in C.  The
installer needs to compile some C libraries to be
called by Python wrapper code and some C libraries
to be called by Haskell wrapper code.  This C code
is generated by code written in Python and
Haskell.

Should the outer layer be autoconf, distutils, or
HPS?

Case 2: Suppose I write a relational database
library that stays outside the IO Monad.  Its just
a a few Haskell files that need to be installed in
the Data directory?

What is the simplest thing that I can do to
package this code?   The full flexibility of
setup.lhs seems like overkill in this case.

Case 3: Suppose I write a http server that library
that relies on a mime-types file....

My gut is that the data file in this case should
be part of the documentation...

Note: I find the runhugs requirement in the
current document frustrating.  I feel like there
should be a command in the local installation like

   hugs -install <setupscript>

and

   ghc -install <setupscript>

etc.

-Alex-
_________________________________________________________________
S. Alexander Jacobson                  mailto:me at alexjacobson.com
tel:917-770-6565                       http://alexjacobson.com