On Tue, 2009-02-10 at 13:43 +0000, Simon Marlow wrote:
Simon Peyton-Jones wrote:
I'm guessing a bit here, but it looks as if you intend this:
* GHC should read Foo.hs, and see {-# LANGUAGE CPP #-} * Then it should run cpp * Then it should look *again* in the result of running cpp, to see the now-revealed {-# LANGUAGE DeriveDataTypeable #-}
I'm pretty sure we don't do that; that is, we get the command-line flags once for all from the pre-cpp'd source code. Simon or Ian may be able to confirm.
Spot on.
If so, then this amounts to a) a documentation bug: it should be clear what GHC does
Right, I checked the docs and it doesn't explicitly say this.
b) a feature request, to somehow allow cpp to affect in-file flags I'm not sure what the spec would be
It needs a bit of thought - what should happen to pragmas that are there pre-CPP but not post-CPP, for example?
If we ever make Cabal do the cpp'ing instead of Cabal getting ghc to do it then it would operate differently. Cabal would look for the LANGUAGE CPP pragma and use that to decide if the module needs to be cpp'ed. Then ghc would get the result after cpp and so get all pragmas post-cpp. Is there any problem with having ghc do the similar thing now? So ghc reads the file and collects the pragmas. From that set of pragmas it discovers that it needs to run cpp on the file. It should now *discard* all the pragmas and info that it collected. It should run cpp and read the resulting .hs file normally. That means it will accurately pick up pragmas that are affected by cpp, just as if the user had run cpp on the file manually. Duncan