state of the cabal (preprocessors)

[Ross Paterson]

On Tue, Oct 19, 2004 at 01:41:53PM +0100, Malcolm Wallace wrote:
> Simon Marlow <simonmar at microsoft.com> writes:
> > 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.

Not very pretty at all.

> > 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.

Hugs's implementation of -F is a bit clunky:
- it slows everything down (Hugs examines most modules twice: first
  to get the imports and later to actually read the whole thing, so a
  preprocessor gets run twice)
- error handling is terrible

I agree with Henrik about doing the preprocessing for Hugs at installation
or packaging time, so that users don't need the full environment.
That's what currently happens with the fptools libraries.