new Library Infrastructure spec.

[Graham Klyne]

At 16:02 02/06/04 +0100, Keith Wansbrough wrote:
> > I think SimonM's suggestion of an RFC2822-like syntax is reasonable, 
> but it
>
>[my suggestion, not SimonM's!]

Oops, sorry!

> > would probably be better to not simply cite RFC2822, since some
>
>I agree, we should give an explicit definition.  I don't think it's
>likely to be very complicated.

Indeed.

> > complications might arise.  An alternative might be XML, which would be a
> > more "modern" choice.
>
>Ugh! No! Please! No!  No reason to do this - remember, this file is
>written by Angela Author, who has just written a Haskell module or two,
>and doesn't have a handly XML structured editor to hand.  She just
>wants to fire up her text editor and write three lines.

I wasn't strenuously arguing for that, just noting a possible alternative.

> > Some nits to look out for with RFC2822 format are:
> > + Internationalization and non-ASCII characters
>
>We should specify either Latin-1 or Unicode/UTF-8.  The latter, I guess.

Yes, Unicode would seem appropriate, and UTF-8 is a popular encoding.

> > + Case (in)sensitivity of header field names
>
>Insensitive would follow the Principle of Least Surprise.

I think so.

> > + No support for structured information (text string values only).
> > + No facility for grouping information
> > + Comments in some header field values
>
>I was imagining that the text string would almost always be a Haskell
>value, using the Haskell lexer and a Haskell-related parser.  This
>would give us comments and structure.

I wasn't aware that there was a comment convention for Haskell *values*, 
just Haskell code.  I guess that's what you meant.

> > + Extensibility model
>
>Yes, this should be specified.  The document already implies "ignore
>headers you don't understand", which is good.

The minimum requirement seems to be a combination of:
(a) ignore what you don't understand, unless
(b) the document says you *must* understand certain headers or fail entirely.


>Try this, using the Haskell Report grammar syntax, and Section 2.2 of
>the Haskell Report for the definitions of <lexeme>, <newline>, and
><whitespace>:
>
><description> ::= { <descline> }
>
><descline> ::= <fieldname> : { <lexeme> | <foldedwhitespace> } <newline>
>
><foldedwhitespace> ::= <whitespace> | <newline> <whitespace>
>
>with the proviso that any <newline> in <foldedwhitespace> has no
>semantic significance.
>
>Alternatively, we could provide Haskell code as specification here.

Sure, that bit's easy enough.  But there's devil in them there 
details.  Not too much, though.

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact