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? Cheers, Simon

| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Alistair Bayley | Sent: Tuesday, February 10, 2009 12:03 PM | To: GHC Users Mailing List | Subject: Re: Pragma not recognised when wrapped in #ifdef | | > {-# LANGUAGE CPP #-} | > #ifdef PRAGMA_DERIVE_TYPEABLE | > {-# LANGUAGE DeriveDataTypeable #-} | > #else | > {-# OPTIONS -fglasgow-exts #-} | > #endif | > -- This file is Test/Fail.hs. | > -- ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail | > module Test.Fail where | > import Data.Generics | > data Fail = Fail deriving Typeable | > | > If compile this wih the command | > ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail | > then I get this error from ghc-6.10.1: | > | > [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) | > | > Test\Fail.hs:11:26: | > Can't make a derived instance of `Typeable Fail' | > (You need -XDeriveDataTypeable to derive an instance for this class) | > In the data type declaration for `Fail' | | | No response. I'd like to know if this is a bug (that's what it looks | like to me), or just a mistake I've made. | | Thanks, | Alistair | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

------------------------------------------------------------------------

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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

| 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. Yes, it does seem anomalous. I suppose the motivation is that some modules might need CPP and some not, and it's convenient for the module itself to announce that fact. Simon

Hi

Is there still a need for CPP now that Template Haskell exists?

Yes. For a start you might need CPP to switch between Haskell compilers that do and don't support Template Haskell! Both technologies do different things, CPP is great for conditional compilation based on compiler version/features - i.e. using either deriving (Eq) or deriving (Data,Typeable,Eq) where the latter is supported. Also for doing imports which have changed between versions, i.e. import Data.Data or Data.Generics depending on version. Using the CPP textual replacement/macro substitution facilities is more debatable, and in many of these cases Template Haskell is a better choice. Thanks Neil

2009/2/11 Simon Peyton-Jones :

...

| 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.

Yes, it does seem anomalous. I suppose the motivation is that some modules might need CPP and some not, and it's convenient for the module itself to announce that fact.

Simon

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users