state of the cabal (preprocessors)

[Malcolm Wallace]

"Simon Marlow" <simonmar at microsoft.com> writes:

> And I suppose the literate version would be .lcpphs? (unlit first, then
> cpp, then Haskell).

Maybe.  Generally speaking, literate comments and cpp markings are
independent, so it doesn't really matter what order you process
them in.  You could define the convention as either .lcpphs or .cpplhs.

> It would be more consistent and arguably correct,
> but I'm not sure that we should do it.

I agree that the issue is not clear cut.

> Another solution is to adopt a new extension for plain Haskell, say
> .phs.  The conversion from .hs to .phs is either via CPP or just 'cat',
> depending on some setting somewhere.

Not very pretty.

> Also, I recommend that we use the compiler itself for preprocessing:
> 
>   ghc -E foo.hs -o foo.phs

You are right that the compiler is best placed to define pp symbols,
so this is all very well, but neither nhc98 nor Hugs currently have
the -E option to stop immediately after pp.  And come to think of it,
the only real reason to have cpp done separately at all is because Hugs
does not have a preprocessor call builtin, like ghc and nhc98 do.
So maybe the best solution is to ship Hugs with -F"cpphs.hugs"
enabled by default?  Then no separate extension would be required,
and Cabal could just defer all cpp-ing to the compiler.

Another thought occurs to me.  Does anyone use cpp markings in
conjunction with any other preprocessors?  For instance, cpp + Happy,
cpp + DRiFT?  What ordering applies there?  I'm inclined to think
that it would nearly always be cpp first, other preprocessors second,
but perhaps not?  After all, the cpp markings would probably still
be conditioned on the end compiler, not on the intermediate pp?

Regards,
    Malcolm