new Library Infrastructure spec.

[Isaac Jones]

Keith Wansbrough <Keith.Wansbrough at cl.cam.ac.uk> writes:

> 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