"S. Alexander Jacobson"
Isaac,
I don't think the "runhugs" bit is a requirement. You can execute the setup script however you like.
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 proposal. On Unix, this might look something like a shell script, let's call it haskell-install, which does the following: wget http://packages.haskell.org/Foo unzip Foo cd Foo-version ./Setup.lhs configure ./Setup.lhs build ./Setup.lhs install # where install --user if run by non-root. or alternately: wget http://packages.haskell.org/Foo unzip Foo cd Foo-version ghc --make Setup.lhs -o setup ./setup configure ./setup build ./setup install This works whether Setup.lhs wraps a makefile system or whether it wraps Distribution.Simple. That is the virtue of having a standard interface, and what I've meant by "layered tools". 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.
Where some.pkg is some combination of tarball and setup specification. The install system of the compiler/interpreter would retrieve some.pkg from the specified location, and use the setup spec to compile it and put it in the appropriate locations such that Joe can use it from his Haskell program or perhaps invoke it as an executable in whatever manner is appropriate to his local OS (mouse-click or command-line).
Right.
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". 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. Marcus has to wrap his makefile system with the Setup script. He uses Distribution.Simple to parse the command-line, but that's it. He doesn't know or care how Joe's operating system implements haskell-install.
Marcus creates packages that require some combination of GCC and Perl and perhaps some random Perl libs from CPAN to build. There is really no way to make installation of systems he creates simple and generic.
Autoconf and friends implement this. We provide an interface which wraps both autoconf and Distribution.Simple. This isn't a new idea, in fact. apt (in Debian) does this, the ports system in BSD does this. Will it work perfectly to be able to install the Perl dependencies for Joe? No. If he wants that kind of support, he'll have to get it from his operating system. In summary, depending on your point of view, there are many ways to make installation of such systems simple and generic.
My feeling is that we shouldn't even bother to try. Marcus and Sam both know enough to communicate effectively to make it happen and neither of them is going to be happy trusting some generic install script to get it right on their totally customized systems!
What's this generic install script you speak of? StaticSetup? Of course, I agree that StaticSetup doesn't get us what we want. Neither will Distribution.Simple, but Marcus isn't using Distribution.Simple. Sam has been perfectly happy for years using "./configure;make;make install".
Angela OTOH knows little about platform dependencies and other stuff and simply wants to make a couple of Haskell libraries available with minimum hassle. Angela would almost certainly prefer a system in which the compiler can guarantee her that her package will install correctly on all conforming Haskell compilers to a system where she has the full freedom to script arbitarily complex installation and make arbitrarily obscure mistakes on any system.
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. OTOH, Marcus needs something more flexible. I'm not sure if you really mean compiler here, but I really don't think this should be closely tied to the compilers (as in the ghc --install example above). Let the compilers compile the code, we'll layer tools on top of the compilers to do the packaging and distribution stuff.
PPS I realize that you really want to suport Marcus as well. Perhaps it might make sense to separate hc-pkg from the rest of the document?
I don't understand what hc-pkg has to do with Marcus in particular? peace, isaac