Re: state of the cabal (preprocessors)

On Tue, Oct 19, 2004 at 01:41:53PM +0100, Malcolm Wallace wrote:

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