haddock-2.3.0 literate comments discarded from .lhs input

Malcolm Wallace Malcolm.Wallace at cs.york.ac.uk
Tue Feb 10 07:07:09 EST 2009

> Aye. The difficulty is we have to have a list of which pre-processors
> to run or not run before using hscolour. Or perhaps we just hope that
> all original sources are ok going through hscolour, even if they're
> not Haskell.

If the pre-processor is going to turn it into Haskell, then I think it
is a fair bet that the majority of the source code will be lexically
compatible with Haskell, no matter which pp we are talking about.  And
in general, the original source will be more readable than the source
after processing.

> > HsColour has -lit and -lit-tex options, to
> > avoid colouring the literate comments from a .lhs.
> I'm not sure what we can do here. We don't know if the file is bird
> track or tex style. Can we get away with always using one option?

I'm guessing that a particular library author is going to stick with the
same style throughout a project, so they could choose to use an option
in the .cabal file?

   hscolour-literate-option: -lit-tex

The semantics would be that Cabal adds the "hscolour-literate-option" to
the HsColour commandline, only for {.lhs, .ly, .lx} files.  If the
hscolour-literate-option is not specified, then it defaults to "-lit".
(The opposite default would of course be possible - I don't know which
style is the majority preference.)


More information about the cabal-devel mailing list