new Library Infrastructure spec.

[Graham Klyne]

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 at haskell.org.

Here are my comments (mostly nits) on:
   http://www.haskell.org/libraryInfrastructure/proposal/libraryInfrastructure.pdf

...

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