new Library Infrastructure spec.

[S. Alexander Jacobson]

Isaac,

Bob wants to install libraries, but has only an
editor and a haskell compiler/interpreter
installed on his machine. Although we can't expect
him to build packages created by Marcus (which
require a C compiler), there is no reason he
shouldn't be able to install packages created by
Angela or Peter Packager (new persona!).

Peter Packager runs the same OS/hardware as
Joe/Bob, but has the tool chain necessary to
compile/build a Haskell Package from Marcus' code.
He supplies Joe with Haskell Packages that include
binaries that run on Joe/Bob's machine.

My claim is that the interface between Marcus and
Peter should be autoconf/make.  Running
"./configure;make" should produce a Haskell
Package which consists only of some combination
of:
  * haskell source
  * binaries for Joe's os/hardware (perhaps for multiple platforms?)
  * documentation/metadata
  * datafiles

Bob can then do e.g. "ghc --install
/path/to/package" ("make install" should also have
the same effect, but that is really up to Marcus.)

Among the consequences of the above:
* Cabal becomes completely declarative
* It may be possible to warn the user if a package
  uses IO or unsafeperformIO and to tell the user
  exactly what binaries are being located where.
* Implementation becomes substantially easier


> The tools should do their job, and do it well.  The compiler compiles,
> the build / install system installs, and you can layer a tool on top
> of that which tracks package databases.

>From a layering perspective, I am advocating a
clean interface between Peter and Bob.  It is
really a communication protocol that will outlast
multiple generations of implementations.

> It is very important to me to support tools by Marcus.  His packages
> are actually the most difficult to manage, and the most confusing for
> an end user.

Agreed.  That is why you need something like
autoconf/make to build them and we can't expect
that of Bob.  The question is whether we can do
better than autoconf/make in producing Haskell
Packages for Bob to install.

> Supporting just tools by Angela would in fact be much
> easier

Good.  My claim is that all you need is to support
Angela plus binaries.

> (except perhaps for implementing things directly in the
> compilers, as you propose).

I don't mean to require that the compiler
implement that interface but rather that you
should not need anything more than a
Haskell compiler/interpreter to install a package.

> Fortunately, I think we can support
> Marcus without making Angela's job harder.

The issue is not Marcus vs. Angela.  It is Marcus
vs. Bob.  I think you need to support
Marcus<->Peter and Peter<->Bob.  I don't see how
you can do better than autoconf/make for the
former and I don't know that there is any support
in the current proposal for the later (including
binaries).

> If we can step back for a moment, I think you're saying that
> supporting Marcus isn't that important, or that it's too hard.  Maybe
> we could break up the argument along the lines of:
>
> 1) Why we should / shouldn't support Marcus
> 2) What would / could a system that just supports Angela look like
> 3) What would a system that supports tools by both Angela and Marcus
>    look like (this proposal is our answer to that).
>
> I'm fairly comfortable that our system is appropriate to answer 3.

autoconf/make already support Marcus.  The people
who need more support are Peter and Bob.

> Haskell-install deals with the execution of the wrapper script.  It
> does so in a platform-dependent way, and can be made to understand
> users' compiler preferences or what-have-you.

The install should not be a script.  It should be
a declarative specification that allows the
installer to warn the user of potentially unsafe
things.

> We actually have a really good idea of what the fields are, but not
> what the format is.

It should be Haskell.  Angela is guaranteed to
understand the syntax and, if you have a Haskell
interpreter/compiler, verification is very easy.

> Fortunately, once we've defined the interface, we
> can put off being precise about the fields. If you get a chance to
> take a look at the code, the package description looks like this right
> now:
>
> data PackageDescription
>     =  PackageDescription {
> 	-- the following are required by all packages:
> 	package        :: PackageIdentifier,
>         licenese       :: License,
>         copyright      :: String,
>         maintainer     :: String,
>         stability      :: String,
>
> 	-- the following are required by the simple build infrastructure only:
>         buildDepends   :: [ Dependency ],
>         allModules     :: [ String ],
>         mainModules    :: [ String ],
>         cSources       :: [ FilePath ],
> 	exposedModules :: [ String ],
>         extensions     :: [ Extension ],
>         extraLibs      :: [ String ],
>         includeDirs    :: [ FilePath ],
>         includes       :: [ FilePath ],
>         options        :: [ (CompilerFlavor, [String]) ]
>     }

Looks good, but I don't think you need all the
C compilation support stuff.  I do think you need
a specification for resolving dependency names to
actual package files so that installing a package
that depends on other packages does not require
multiple manual download install processes given a
complete archive (CHAN?).

> > Is there some substantive problem with
> > autoconf/make with respect to Haskell such that it
> > needs to be wrapped with Setup.lhs?
>
> No.  It's a matter of providing a common interface to users and tools.

They are two distinct needs/users.  Marcus
delivers an autoconf/make file to Peter.  Peter
delivers a haskell package to Bob/Joe.

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