On 02 June 2004 11:20, Keith Wansbrough wrote:
>> We would welcome your feedback, either as a potential library or tool
>> author, or as a potential consumer, or both. The specification isn't
>> complete in every detail, but it seems better to post it before
>> investing in details that may be rendered void by subsequent
>> discussion.
>
> This looks great! A few comments:
>
> 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.
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.
> 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
>
> <fieldname> ":" <fieldbody>
>
> ; then long lines may be "folded" by breaking them anywhere
> <whitespace> is allowed, by inserting <newline><whitespace>.
>
> To read this format back, first "unfold" by replacing all
> <newline><whitespace> pairs with <whitespace>; then expect
> <fieldname> ":" at the start of each line, with the remainder being
> <fieldbody>.
I like this.
Cheers,
Simon
