new Library Infrastructure spec.

[Isaac Jones]

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

> Also, I disagree with "They [Roland et al] do this
> as a service for Angela Author and the community."
>
> 1. Peter does this as a service for users of the
>    platforms his packages target not for Angela or
>    Marcus (it could be a disservice to A&M if they
>    didn't want their packages distributed!)

OK.  I'm sure there are many reasons Rowland et al package things.

> 2. Contrary to the proposal, those users should
>    NOT need Peter's services to install Angela's
>    pure haskell packages (the 99% case).

That's not contrary to the proposal.  Such users don't *need* Peter's
packages, but if they exist, the users will probably use them.  (I
know I would, and as a consumer of those packages, I don't care
whether they're authored by Angela or Marcus.)

(snip)
> In any case, it seems much more important to flesh
> out the end-users experience and in particular the
> Windows end-user experience as it is probably the
> most common (and perhaps majority) case.

I'll add more personas and use cases to the proposal, and I will
clarifiy those that are there.  I will also clarify that these
personas are not necessarily disjoint, since they're really more like
use cases.

>> The reason that case is not included in this proposal is that it's
>> outside the system as it stands now.

> Yup.  That is our disagreement.  You are laundering in that user by
> wanting to wrap .rpm w/ setup.lhs.

We do not propose to wrap .rpm with Setup.lhs.  Confused statements
like this make me fear that you still do not understand my viewpoint.

>  My claim is that there are only two scenarios:
>
> (1) Marcus -> Peter -> Wally/PNW
> (2) Angela -> Wally/PNW

Of course there are many more scenarios.  What do you mean that there
are only two?  In fact, many Haskell programmers are probably nothing
like PNW in that they know other programming languages and can compile
tools written in other programming languages.

> In scenario 1, I don't see what value the proposal
> adds over that provided by make/autoconf for
> Marcus -> Peter and InstallShielf for
> Peter->Wally/PNW.

I have explained this:

1) A consistent interface to users
2) A consistent interface to layered tools (of which I have given
   several examples)

(snip)
>> All you're saying here is that your scheme doesn't support Marcus.
>> I'm still waiting to hear why he's not important.
>
> No.  I'm saying that YOUR scheme doesn't really
> support Marcus.  Or, more particularly, I'm saying
> that I don't see the value your scheme provides
> over autoconf/make -- especially given the
> assumption that Peter knows little or nothing
> about Haskell.

We provide Peter with value because all Haskell tools conform to a
common interface, no matter whether Angela or Marcus wrote them.
Packaging them therefore becomes easier.

For instance, please take a look at the Common Debian Build System
(cdbs), for which we can make a Haskell target to make Donald's job
easier.  I've mentioned this before.  This is an example of layered
tools.  Note that cdbs isn't dpkg (the tool that installs debian
packages).

>> This character (please, not Wally) can't install Marcus's package
>> whatsoever.  He's in no better or worse shape than before.  For
>> packages that "PNW" can install, our system still supports him.
>
> But you can help Peter by giving him a simple
> interface that RPM or Installshield or whatever
> can use to install the Haskell specific
> components!  

Yes. That is what we're doing.  This interface works for packages by
both Angela and Marcus.

> If Peter knows little about Haskell, it makes little sense to force
> him to write a Setup.lhs that calls InstallShield.

You are still confused.  Peter doesn't write Setup.lhs, and Setup.lhs
doesn't call InstallShield.  I still hold out hope that once you
understand our proposal you will like it more than you seem to.

(snip)
> The proposal already makes demands on compiler
> authors and the proposal is for a mechanism to
> support mucking about in the files on which the
> compiler relies.

That the compiler authors have to implement hc-pkg is not a large
demand, as it's very useful for lots of stuff, and I believe there are
simple implementations for it already.  It is not vertical integration.

> How does the setup.lhs author know in which directory to put library
> files?
(snip)

It depends on which author.  Angela just calls defaultMain, which
implements configure which figures that stuff out.

Marcus presumably uses autoconf to figure it out.

Bob (or the author of haskell-install) can over-ride the choice with
flags to configure.

Also, it doesn't particularly matter where they go, because register
tells the compiler where they are.

BTW, how does your system figure out where to put the libraries?

> The document describes this workflow:
>
>   ./Setup.lhs configure --ghc
>   ./Setup.lhs build
>   ./Setup.lhs install
>
> So this means that Angela needs to know how to
> install her package for GHC? and NHC?  

Nope.  Another clear point of confusion, and a huge one.  The
Distribution.Simple module does that for her.

(snip)

> What happens if I've customized my local config substantially?

Then you should know how to pass options to ./Setup.lhs configure, or
you should somehow make your customization information available to
haskell-install.

I can see that the proposal is lacking in a number of areas, and I
hope to fix that.  You have highlighted a few concrete areas where we
need to be more clear.  That said, but the proposal is meant to
introduce the system at a high level, and as I say on the web page, I
expected people to be familiar with previous discussions on this list.

I hope you will take the time to fully understand our system before
you continue to condemn it.  Please do go to the trouble of reading
the old proposal and my presentation, and even some of the list
archives.  These are all linked to on the "library infrastructure"
front page.


peace,

  isaac