GHC's CPP and Cabal's unlit
alistair at abayley.org
Thu Jan 10 09:25:41 EST 2008
> > 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 58970 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080110/e29a4f42/unlit_period_for_blank_comment-0001.obj
More information about the cabal-devel