state of the cabal (preprocessors)
ross at soi.city.ac.uk
Tue Oct 19 12:49:54 EDT 2004
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.
More information about the Libraries