GHC's CPP and Cabal's unlit

[Alistair Bayley]

> > Yes, choosing to use non-empty whitespace (to indicate that a comment
> > block is not finished) might well be a poor design decision. Another
> > possibility is to use a line containing a single period as a
> > continuation line e.g.
>
> I think we do this in Cabal descriptions (copying the design from Debian
> package's descriptions), so this would be consistent with that. It gets
> my vote!

I have implemented this, and made a couple of other changes:
 - use a single period on a line to indicate that we want to continue
the comment block (like cabal does)
 - don't indent code relative to comments, because Haddock doesn't like this
 - reverse Left and Right cases in the Either returned by unlit, so
that they're consistent with Either conventions (Left == failure,
Right = success)
 - reclassify is simpler because there's no need for lookahead for the
blank-followed-by-code case

I've also updated the test module and the calling code in ppUnlit in
PreProcess (because the Left and Right cases are reversed).

I wanted to send a separate patch for each source file, but my
darcs-fu is poor, and darcs insisted on including a bunch of older
patches which are already in my repo and the main cabal repo. So it's
all in one fat patch, which seems to include a bunch of older patches
it depends on. I don't know why this is; I expected that "darcs pull"
would have updated my repo w.r.t. the main cabal repo, so that this
wouldn't be necessary.

I'll try to get Haddock 2 soon and see how it fares with .lhs input.

Alistair
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unlit_period_for_blank_comment.patch
Type: application/octet-stream
Size: 58970 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080110/e29a4f42/unlit_period_for_blank_comment-0001.obj