state of the cabal (preprocessors)

Graham Klyne GK at
Tue Oct 19 11:13:42 EDT 2004

At 12:46 19/10/04 +0100, Simon Marlow wrote:
>Also, I recommend that we use the compiler itself for preprocessing:
>   ghc -E foo.hs -o foo.phs

Er, shouldn't it be possible to use Cabal with a system that has just Hugs 


At 12:46 19/10/04 +0100, Simon Marlow wrote:
>On 19 October 2004 09:58, Malcolm Wallace wrote:
> > Isaac Jones <ijones at> writes:
> >
> >> The issue with cpp is that we can't go by extensions as we do with
> >> the rest of the preprocessors... There is a function in HMake which
> >> tests to see if a file needs to be cpp'd, so we can employ that.  I
> >> think we'll probably have to just treat cpp a little differently
> >> from the others, unfortunitely, and I haven't gotten around to it.
> >
> > On the other hand, you could reject the convention that cpp sources
> > are not distinguished by file extension - e.g. create a new convention
> > that, say, a .cpphs extension is preprocessed by cpp(hs) to get a
> > plain .hs file.
> >
> > Since Cabal is pretty new, this won't break any existing Cabal
> > packages, and when converting non-Cabal packages to Cabal, there is
> > some work to do anyway, so why not just adopt this as one extra rule
> > to follow?
> >
> > This is just a suggestion - I'm in two minds whether it is a good
> > idea myself, but it is at least worth considering the possibility.
>And I suppose the literate version would be .lcpphs? (unlit first, then
>cpp, then Haskell).  It would be more consistent and arguably correct,
>but I'm not sure that we should do it.
>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.  Also, I recommend that we use the
>compiler itself for preprocessing:
>   ghc -E foo.hs -o foo.phs
>because only the compiler knows what the values for the preprocessor
>symbols __HASKELL__, __GLASGOW_HASKELL__, i386_TARGET_ARCH etc. should
>be.  Otherwise we'll have to run the compiler during ./setup configure
>to find out the values of these symbols (isn't that what hmake does?
>What about when a new compiler comes along?).
>         Simon
>Libraries mailing list
>Libraries at

Graham Klyne
For email:

More information about the Libraries mailing list