Re: Pragma not recognised when wrapped in #ifdef
On Tue, 2009-02-10 at 13:43 +, 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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Pragma not recognised when wrapped in #ifdef
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 > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Pragma not recognised when wrapped in #ifdef
Is there still a need for CPP now that Template Haskell exists? 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
RE: Pragma not recognised when wrapped in #ifdef
| 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
Re: Pragma not recognised when wrapped in #ifdef
On 2009 Feb 10, at 8:55, Alistair Bayley wrote:
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.
Or require the CPP pragma to be the first thing in the file,
immediately triggering cpp and a reread. This means
> #if 0
> {-# LANGUAGE CPP #-}
> #endif
is ambiguous, but I think it could be argued that the programmer has
asked for _|_ and any behavior is acceptable.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH
PGP.sig
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Pragma not recognised when wrapped in #ifdef
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Pragma not recognised when wrapped in #ifdef
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-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Pragma not recognised when wrapped in #ifdef
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
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@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
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
Pragma not recognised when wrapped in #ifdef
I have this little test program:
{-# 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'
I've checked the preprocessor output with -E, and that looks fine. I
can compile the preprocessor output with ghc without errors.
Alistair
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
