Graham Klyne
General:
After a first reading, I find myself a little confused about the module naming invariant (sect 2.2), and subsequent comments about prefixes (e.g. 4.2.1, 4.2.3). I think that the term "prefix" is used exclusively to refer to file location, but the name suggests something "deeper" is intended.
True. Can you suggest a wording that would be more clear? For instance, the explanation of the flags in section 4.2 say that they "specifies where the installed files for the package should be installed". What if I change it to: "specifies where the installed files for the package should be installed (ie the location of the files themselves)."
I'm also (mildly) concerned that the invariant might create problems for distributing and installing large libraries (cf. the problem noted in section 3.1.2).
While appreciating the desire noted in 2.2 for avoidance of complexity, I can't help wondering if there's a "minimal" approach to qualifying module names that would allow module version-mixing in a program. I'm thinking of something like a "hidden" qualification of each module name that is derived from the particular source of the module (location, hash of content, or something else). Then, different versions of a module might be made visible to different source files without prohibiting multiple versions appearing in a program. The details of such differentiation would be entirely compiler dependent, so I think the design space is not unduly prejudiced.
These issues involve tricky compiler symbol naming issues which I won't comment on (maybe one of the compiler hackers can explain). Perhaps in the future, we can relax these requirements, however.
Section 1.2 and elsewhere:
I find the use of Unix scripting features may be less easy to operate on (say) Windows systems. I think Simon Marlow's suggestion may be better: (snip runhaskell explanation)
I just commented on this in my reply to Keith. This scripting feature is a convenience for Unix and has no real effect on the behavior for windows. In windows, the script must somehow be executed. In any system, the user may choose to compile the module by hand. One thing that the windows community might do is write a program which reads the first line of an .hs or .lhs file to see if it's a #! line, and if so executes it with the given compiler, if not, drops you into an interpreter, or an editing environment or whatever. I just don't know what the default double-click behavior for windows should be, really. Can you have a right-click "Open With" context menu? Can windows prompt you with the options (run, load in interpreter, or edit)?
Section 1.2:
I noticed the comment "tests and design notes may be omitted", and it occurred to me that this was slightly counter to the message one might to give out.
That's a good point, though it was just an example of something that might be in your source tree that you don't want to distribute.
I think it would be good if the infrastructure design encouraged the distribution of self-contained self-test programs that can be used to verify an installation (or, at least, give some confidence in it). I find the availability of tests makes cooperative development of software much easier to get right, and I think that's part of what we want to achieve here, n'est ce pas?
I highly agree.
So what's my concrete suggestion? Maybe (a) to emphasize the Setup test option (sect 4.2), and (b) define a default location in the install path for a test suite, or an entry in the package description (4.1, and elsewhere) specifying a command to run the test suite.
It occurs to me that this is one of the tasks that can be implemented somewhat independently of most of the system.
I think the name 'pkg.desc' is a bit cryptic.
For such a key file that appears in the root of a package distribution, I think a more descriptive file name could be used. Why not "package.description"? Or, taking a lead from the Python distutils mentioned in A.2, "Setup.description" (using the filename stem "Setup" for the program and the configuration helps to emphasize that they work together.)
I like Setup.description.
Section 3.1:
First bullet: now that it's available and works well, I suggest mentioning 'cpphs' rather than just 'cpp', the latter being rather system-dependent.
OK.
Section 3.1.1, final para:
I found this paragraph really hard to understand. It seems to be contradicting itself (...are separate...all use the same user packages...), but maybe I'm just not understanding.
It says that since the package database depends on the compiler and version, you should be careful if you have two installations of the same compiler and the same version. Lets say that a user mounts his home directory on his linux machine and on his solaris machine. He also uses ghc-6.2 on both machines. His user packages are installed in ~/ghc-6.2-packages (or something) and are compiled for Linux. Now he had better be careful using the solaris version of the compiler, because his packages are compiled for Linux, and they're in a spot where the solaris compiler will find them! Maybe we should also break them up via platform or something, as hmake does.
Keep up the good work!
Thanks :) peace, isaac