Pragma not recognised when wrapped in #ifdef

[Alistair Bayley]

2009/2/10 Simon Peyton-Jones <simonpj at microsoft.com>:
> 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