Keith Wansbrough
This looks great! A few comments:
Thanks :)
1. In the document, Angela uses `#! runhugs' or `#! runghc' at the top of her Setup.lhs. But Joe is running an nhc install. Angela can't know which compiler Joe is using, and so she shouldn't have to specify at the top of Setup.lhs. I propose that she write `#! runhs' instead, and the compiler writers all provide a `runhs' script (or symlink) as appropriate.
This is an idea that I've been promoting for over a year :) Simon Marlow recently implemented runghc, btw. It would be great to have a runhaskell. It doesn't actually matter which haskell implementation Joe is using to execute the Setup script, since he specifies the target compiler on the command-line. The reality is that Joe is meant to execute the setup script however he can. He can even compile it and run the executable. We'll somehow have to make this clear in the end-user documentation, until we can deploy a runhaskell script to standardize things. I'll try to clarify the document in this regard. I imagine that in a GUI environment like windows, you can execute the script via some kind of GUI wrapper that understands the Setup interface.
2. In section 4.1, the syntax for pkg.desc is discussed. I think the simplest and least surprising syntax to use would be the RFC-2822 email message header syntax (specifically sections 2.2 and 2.2.3). That is, each field is first written as
I'm leaning toward the Haskell read / show syntax.
3. In section 3.1.3, it is unclear whether a user package (on being registered) may expose a module with the same name as one in an (already-existing) system package.
I believe that it is fine for a user package to expose a module that's already exposed by a system package. I hope SimonPJ can confirm, though.
In section 3.2, is the checking mentioned at the end of the section performed lazily or eagerly? (i.e, if the program does not mention a module name that overlaps, is this still an error?).
IMO, it should be eager, and I think that the Simons and Malcolm agreed about that (correct me if I'm wrong). Take this for-instance: - The user uses packages P and Q, with overlapping module name M. She uses module A from P and module B from Q, but not module M and the compiler allows this (this is the "lazy" approach). - This goes on for a long time, and she has lots of code that depends on both P and Q. - Suddenly, she wants to use module M from package P, which is completely different from module M from package Q. She is stuck, and now has to choose between module M and package Q, which she will have to back out of. Better to stop her early before she becomes dependent on Q. Oh, and there are other issues where if P:A depends on P:M then if the compiler needs to stick Q:M in the same program, it'll have to qualify the module symbols with the package name (and version?) This isn't my area, though. Can you suggest a wording which would make it unambiguous that this is eager?
5. In three places you say "setup" rather than "./Setup.lhs": s4.2.1 bullet 1, s5.4 "setup configure" and "setup build".
Thanks. It is actually possible that ./setup is a compiled program that the user wants to run, but it would be best to be consistent.
--global under 4.2.3 should repeat the rubric of --user regarding "This flag has no effect under --install-prefix".
Period missing at end of s3.0 sentence.
Thanks. peace, isaac