new Library Infrastructure spec.
S. Alexander Jacobson
haskell at alexjacobson.com
Mon Jun 7 17:19:30 EDT 2004
On Mon, 7 Jun 2004, Isaac Jones wrote:
> > Any reason we can't simplify Joe's interface to:
> > ghc --install http://url/of/some.pkg
> > --or--
> > hugs --install /path/to/some.pkg
> This is quite explicitly something we're trying to support. The
> original document, and my talk at the Haskell Implementor's Meeting,
> had some exampled of "layered tools" for the system, including exactly
> this use. I should probably re-add that to this version of the
This interface should be _fundamental_. JoeBob*,
and Sam are indifferent to how it is implemented.
It should just work if the compiler/interpreter is
[...sample shell script implementations elided
because implementation is irrelevant to this
discussion... question: Why are the sample
implementations not themselves in Haskell!?...]
> One version of haskell-install is written for Windows, one for
> unix-a-likes. Or maybe Debian will implement one to set the --prefix
> flag to /usr/local/ghc/libs or something.
Whatever. Just so long as all JoeBob has to do is
"gnhugc --install foo.pkg"
> > The open question is what this setup specification
> > should look like. There is an obvious tradeoff
> > between the interests of Joe and Angela on the one
> > hand and Marcus on the other.
> I think our scheme satisfies Joe, Angela, and Marcus. All Joe knows
> is that he says "haskell-install".
At least in the proposal so far, someone has to
deal with "runhugs" or whatever. --install should
be standard for every compiler/interpreter just
> All Angela knows is that she fills out the (declarative) fields
> required by Distribution.Simple. She doesn't know or care how Joe's
> operating system implements wget.
Or even IF Joe's os implements wget. Why not
implement in Haskell to avoid this issue?
> Angela does have this. She can use Distribution.Simple. She's not
> doing arbitrary or obscure IO. The example we give is very
> declarative for her.
Sorry, where is the example. 1.2 does not include
telling the system that Angela.Internals is
private to Data.Set and Data.Bag. 3.4 is empty
as is 5.3.
My concern here is in particular that the
(declarative) fields are not yet fleshed out even
though they are the most important part of this
sort of proposal!
> Autoconf and friends implement this. We provide an interface which
> wraps both autoconf and Distribution.Simple.
> Sam has been perfectly happy for years using "./configure;make;make
So, why are you making Sam do something different
> OTOH, Marcus needs something more flexible.
Is there some substantive problem with
autoconf/make with respect to Haskell such that it
needs to be wrapped with Setup.lhs?
If I have a package that is part C, part Python,
and part Haskell, why is it reasonable to assume
the outer-layer is necessarily Haskell as opposed
to e.g. Python's dist-utils? Or does Marcus need
to strategize whether the outer layer is
dist-utils or HPS and then have one call the
Note: I read section 2.5, but that seems like an
argument for writing an package system in Haskell
regardless of the language of the code to be
installed. All of which takes us back to my prior
point about using Haskell to address generic
problems in autoconf/make rather than solving the
Haskell package problem in particular
* I don't believe Joe and Bob are different people
so I am consolidating them as JoeBob. In
particular I don't believe that Joe user should
have to get someone else's help to do a simple
S. Alexander Jacobson mailto:me at alexjacobson.com
More information about the Libraries