GHC's CPP and Cabal's unlit

Alistair Bayley alistair at
Sat Jan 5 18:14:44 EST 2008


Sorry, I haven't had time to look at your patch yet. Still on holiday.

> Alistair, can you remind us why we need the ability to break paragraphs into
> multiple comments rather than a single comment?

One example:

In Takusen's Database.Enumerator module we use named chunks. The
chucks are all placed at the end of the file. A given chunk may
contain many paragraphs, but it must consist of a single comment
block. Separate chunks must be in separate comment blocks (I assume; I
haven't actually tested this).

Another example:

Let's say you want to produce this .hs output for Haddock:

-- | A description of x
-- some more comments about x

x = ...

Now imagine you want to produce this .hs:

-- | A description of x

-- some comments which are interesting but we don't want Haddock to use them

x = ...

What do you write in your .lhs file to produce these outputs? I chose
a fairly simple rule: a line containing some whitespace chars
continued the current comment block, while a truly empty line ended

> > Invisible whitespace is generally ignored elsewhere in Haskell
> I agree, whatever distinction might be necessary it should not be done on the
> basis of something that's invisible.

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.

line 1
line 2


-- line 1
-- line 2

... while whitespace only just outputs an empty line (no comment). Do
you think that is a better choice?

The extra state idea might be an improvement over the current design.
Currently we have to look ahead in the comment state to decide to
transition to the blank or comment states. An extra state would
probably avoid the lookahead. I'll try it out to see how well it


More information about the cabal-devel mailing list