state of the cabal (preprocessors)

[Simon Marlow]

On 19 October 2004 09:58, Malcolm Wallace wrote:

> Isaac Jones <ijones at syntaxpolice.org> 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?).

Cheers,
	Simon