2009/2/10 Simon Peyton-Jones
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.
If so, then this amounts to a) a documentation bug: it should be clear what GHC does b) a feature request, to somehow allow cpp to affect in-file flags I'm not sure what the spec would be
I see. So ghc will scan the source initially for pragmas, and add any it finds as command-line flags. Having done that, it then proceeds through the normal processing pipeline. I had assumed (from the manual section 5.4.3) that the pipeline was this: - unlit - cpp - haskell compiler - c compiler (defunct?) - assembler - linker and I also assumed that the pragmas would be parsed by the haskell compiler i.e. post unlit and cpp. It hadn't occured to me that this implementation would make the CPP pragma redundant... and the implications thereof. I'd love (b), but will settle for (a) for now. I was trying to use cpp to switch between the DeriveDataTypeable pragma for 6.10, and glasgow-exts for 6.8 and 6.6. I've decided to push this out to the cabal file instead, so I guess I don't have this problem any more, but it was a bit puzzling. Perhaps CPP shouldn't be a pragma, just a command-line flag? It seems to be the only one that affects/involves preprocessor(s). AFAICT, the others all affect the haskell compiler stage. Alistair