At 14:49 01/06/04 -0400, Isaac Jones wrote:
We hope this will be an important spec, and will be with us for a long time. So now's the time to look at it. Send feedback to libraries@haskell.org.
Here are my comments (mostly nits) on: http://www.haskell.org/libraryInfrastructure/proposal/libraryInfrastructure.... ... 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. 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. ... 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: [[ Probably better than a symlink is to have a 'runhaskell' program that dynamically looks for a compiler to run, based on an order of preference. Then runhaskell can be distributed separately, and there's no retargetting of symlinks required when compilers are installed or uninstalled. This is like the runghc I wrote recently: it searches for a ghc binary in the path, so that I don't have to wire in the path to ghc when runghc is built. ]] (Noting that each Haskell compiler can include a 'runhaskell' so that systems with just one compiler are automagically "ready to run". If that 'runhaskell' is the same for multiple systems, then so much the better. ... 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. 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? 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. ... Sections 2.5, 4: 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.) ... 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. ... Section 3.1.1 I think the whole matter of --global and --user packages may be rather system-dependent. I (really!) look forward to a not-too-distant future in which I can write Haskell programs for my Palmpilot, maybe even developing code *on* such a device. (IMO, Haskell's compact syntax makes it well-suited for such use.) I don't think the concept is wrong, but just that it should be recognized that not every system will support the distinction. In standards-lingo, this material may be a SHOULD rather than a MUST. ... 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. ... Description file syntax: I think SimonM's suggestion of an RFC2822-like syntax is reasonable, but it would probably be better to not simply cite RFC2822, since some complications might arise. An alternative might be XML, which would be a more "modern" choice. Some nits to look out for with RFC2822 format are: + Internationalization and non-ASCII characters + Case (in)sensitivity of header field names + No support for structured information (text string values only). + No facility for grouping information + Comments in some header field values + Extensibility model I think it would be good to include a commenting convention. (Use Haskell conventions -- and {- ... -} ?) ... Keep up the good work! #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact