new Library Infrastructure spec.

[Isaac Jones]

Graham Klyne <GK at ninebynine.org> writes:

> 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