RFC: "Native -XCPP" Proposal

Herbert Valerio Riedel

6 May 2015 6 May '15

7:08 a.m.

Hello *, As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor. This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out). So please go ahead and read the Wiki page... and then speak your mind! Thanks, HVR [1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics?

Show replies by date

Jan Stolarek

6 May 6 May

7:38 a.m.

One thing to keep in mind is that while cpphs will solve some problems of system-cpp, it will also bring problems of its own. I, for one, have run into problems with it when installing Agda. There is a very long thread here: https://lists.chalmers.se/pipermail/agda/2014/006975.html and twice as more on my private inbox. We've reached no conclusion about the cause and the only solution was to use system-cpp. Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements." Janek [1] http://projects.haskell.org/cpphs/ Dnia środa, 6 maja 2015, Herbert Valerio Riedel napisał:

...

Hello *,

As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor.

This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page

https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out).

So please go ahead and read the Wiki page... and then speak your mind!

Thanks, HVR

[1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics?

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

--- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

Andrés Sicard-Ramírez

9:43 a.m.

I want to emphasize that cpphs is actively maintained as it's pointed out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The Agda team has found some cpphs bugs which have been *quickly* fixed by cpphs's author, Malcolm Wallace. Unfortunately I have not been able to track down the problem mentioned by Janek Stolarek. On 6 May 2015 at 06:38, Jan Stolarek wrote:

...

One thing to keep in mind is that while cpphs will solve some problems of system-cpp, it will also bring problems of its own. I, for one, have run into problems with it when installing Agda. There is a very long thread here:

https://lists.chalmers.se/pipermail/agda/2014/006975.html

and twice as more on my private inbox. We've reached no conclusion about the cause and the only solution was to use system-cpp.

Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements."

Janek

[1] http://projects.haskell.org/cpphs/

Dnia środa, 6 maja 2015, Herbert Valerio Riedel napisał:

...
Hello *,

As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor.

This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page

https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out).

So please go ahead and read the Wiki page... and then speak your mind!

Thanks, HVR

[1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics?

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

--- Politechnika Łódzka Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- Andrés

Jan Stolarek

3:55 p.m.

...

I want to emphasize that cpphs is actively maintained as it's pointed out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The Agda team has found some cpphs bugs which have been *quickly* fixed by cpphs's author, Malcolm Wallace. Yes. It was not my intention to imply in any way that cpphs suffers from maintanance issues.

...

Unfortunately I have not been able to track down the problem mentioned by Janek Stolarek. Yes, and that's what gets me worried. I suppose the problem was somehow related to my locale settings although we were unable to track down the cause. I also recall someone else reported being affected by the same problem. So, until that problem is solved I would say it is a blocker as it would essentialy make development of GHC impossible for some people.

Janek

...

On 6 May 2015 at 06:38, Jan Stolarek wrote:

...
One thing to keep in mind is that while cpphs will solve some problems of system-cpp, it will also bring problems of its own. I, for one, have run into problems with it when installing Agda. There is a very long thread here:

https://lists.chalmers.se/pipermail/agda/2014/006975.html

and twice as more on my private inbox. We've reached no conclusion about the cause and the only solution was to use system-cpp.

Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements."

Janek

[1] http://projects.haskell.org/cpphs/

Dnia środa, 6 maja 2015, Herbert Valerio Riedel napisał:

...
Hello *,

As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor.

This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page

https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out).

So please go ahead and read the Wiki page... and then speak your mind!

Thanks, HVR

[1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics?

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

--- Politechnika Łódzka Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Andrés Sicard-Ramírez

5:47 p.m.

Hi Janek, On 6 May 2015 at 14:55, Jan Stolarek wrote:

...

Yes, and that's what gets me worried. I suppose the problem was somehow related to my locale settings although we were unable to track down the cause. I also recall someone else reported being affected by the same problem.

AFIK, the only cpphs-Agda open problem is your problem. I would like to know if anyone else has some problem. If so, I propose to move the discussion to the Agda developers list (agda-dev@lists.chalmers.se). Best, -- Andrés

Herbert Valerio Riedel

7 May 7 May

3:54 p.m.

On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...]

...

Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements."

Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_prop...

Malcolm Wallace

4:41 p.m.

I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote:

...

On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote:

[...]

...
Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements."

Fyi, Neil talked to him[1]:

| I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal.

[1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_prop...

Austin Seipp

6 May 6 May

8:25 a.m.

On Wed, May 6, 2015 at 6:08 AM, Herbert Valerio Riedel wrote:

...

Hello *,

As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor.

This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page

https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out).

So please go ahead and read the Wiki page... and then speak your mind!

Thanks for writing this up, btw! It's nice to put the mumblings we've had for a while down 'on paper'.

...

Thanks, HVR

[1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics?

There are two (major) differences I can list, although I can only provide some specific examples OTTOMH: 1) Clang is more strict wrt language specifications. For example, GCC is lenient and allows a space between a macro identifier and the parenthesis denoting a parameter list; so saying 'FOO (x, y)' is valid with GCC (where FOO is a macro), but not with Clang. Sometimes this trips up existing code, but I've mostly seen it in GHC itself. 2) The lexing rules for C and Haskell simply are not the same in general. For example, what should "FOO(a' + b')" parse to? Well, in Haskell, 'prime' is a valid component from an identifier and in this case the parse should be "a prime + b prime", but in C the ' character is identified as beginning the start of a single-character literal, and a strict preprocessor like Clang's will reject that. In practice, I think people have mostly just avoided arcane lexer behaviors that don't work, and the only reason this was never a problem was because GCC or some variant was always the 'standard' C compiler GHC could rely on.

...

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

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Mikhail Glushenkov

9:03 a.m.

On 6 May 2015 at 14:25, Austin Seipp wrote:

...

2) The lexing rules for C and Haskell simply are not the same in general.

One area where this is irritating is that it makes it impossible to use Haskell multiline strings together with CPP.

Karel Gardas

9:56 a.m.

Herbert, what about to extend plan (1) to also include cpphs as a bundled option with all cpphs advantages except no more fork/exec as the bundle will be in a form of binary application and not library? Shall I add it? I would not like to make a mess from your page... Thanks, Karel

Stephen Paul Weber

11:36 a.m.

...

As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor.

Yes. This is one of my favourite things in GHC-land -- that an existing, good-enough, standardised, and widely-deployed solution was chosen over a NiH reinvention of preprocessing. This allows other Haskell compilers to support CPP on basically any system (since cpp is so standard) without much effort, or even if the compiler does not support {-# LANGUAGE CPP -#} the user can easily run `cpp` over the source files themselves before feeding the source into the compiler. Because it is a real `cpp` being used, the developmer must take care to follow the CPP syntax in the file that will then be transformed into Haskell by `cpp` in the same way that C, C++, and other developers have to take extra care (especially around use of # and end-of-line \) when using `cpp`, but this is the normal state of affairs for a secondary preprocessor step. As a benefit, the source code will be processable by standard `cpp` implementations available for virtually every platform. In short, the current solution provides a very robust and portable way to do pre-compile preprocessing, and I like it very much.

Herbert Valerio Riedel

12:09 p.m.

On 2015-05-06 at 17:36:05 +0200, Stephen Paul Weber wrote:

...

...
As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor.

Yes. This is one of my favourite things in GHC-land -- that an existing, good-enough, standardised, and widely-deployed solution was chosen over a NiH reinvention of preprocessing. This allows other Haskell compilers to support CPP on basically any system (since cpp is so standard) without much effort, or even if the compiler does not support {-# LANGUAGE CPP -#} the user can easily run `cpp` over the source files themselves before feeding the source into the compiler.

Because it is a real `cpp` being used, the developmer must take care to follow the CPP syntax in the file that will then be transformed into Haskell by `cpp` in the same way that C, C++, and other developers have to take extra care (especially around use of # and end-of-line \) when using `cpp`, but this is the normal state of affairs for a secondary preprocessor step. As a benefit, the source code will be processable by standard `cpp` implementations available for virtually every platform.

In short, the current solution provides a very robust and portable way to do pre-compile preprocessing, and I like it very much.

The problem I have with that line of argument is that we're using the so-called 'traditional mode' of `cpp`[1] for which afaik there is no written down common specification different implementations commit to adhere to (well, that's because 'traditional mode' refers to some vague implementation-specific "pre-standard" cpp semantics). And how is the developer supposed to take care to follow the (traditional mode) CPP syntax, if he can't test it easily with all potentially used (traditional-mode) `cpp`s out there? This already has led to problems with Clang's cpp vs GCC's cpp. Moreover, I was under the impression that it's only a matter of time till `traditional mode` support may be dropped from C compiler toolchains. Otoh, we can't use an ISO C spec conforming c-preprocessor, as that would conflict even more heavily w/ Haskell's grammar to the point of being inpractical. [1]: https://gcc.gnu.org/onlinedocs/cpp/Traditional-Mode.html

Brandon Allbery

12:47 p.m.

On Wed, May 6, 2015 at 11:36 AM, Stephen Paul Weber < singpolyma@singpolyma.net> wrote:

...

Yes. This is one of my favourite things in GHC-land -- that an existing, good-enough, standardised, and widely-deployed solution was chosen over a NiH reinvention of preprocessing

I have to assume my irony detector is broken as well. Or maybe I should just assume that "all the world's Linux with gcc" is assumed to be forever true and forever reliable by "all right-thinking people" so let's just sweep the nonissue under the rug because it can oh so obviously never be a real issue.... Because I had to face this back a couple decades ago, when my employer ported an application written in a 4GL (database language) to SCO Unix. The 4GL assumed cpp was the ever reliable pcc one and broke very badly when SCO used one integrated into its lexer (making it even more tightly wedded to C syntax than clang's). Eventually we replaced its cpp with a wrapper that ran m4 and redid everything else in m4's syntax. Which is why I was always a bit worried about ghc relying on cpp, was unsurprised when clang caused issues, and am rather annoyed that there are people who believe that they can just ignore it because REAL users will always be on Linux with gcc and all them furriners using weird OSes like OS X and FreeBSD can safely be ignored with their not-the-One-True-OS-and-compiler platforms. Additional historical note that I assume True Believers will ignore as meaningless: X11 used to make the same assumption that cpp was always and forever guaranteed to be friendly to non-C and this still shows at times in things like xrdb resource databases. They did accept the inevitable and (mostly) stop abusing it that way, and are now moving away from imake which likewise assumes it's safe to use cpp on Makefiles. (And yes, I encounter the same inability to comprehend or accept change there.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Herbert Valerio Riedel

18 Jun 18 Jun

4:32 a.m.

New subject: Native -XCPP Conclusion (was: RFC: "Native -XCPP" Proposal)

Hello *, Following up on the "Native -XCPP" Proposal discussion, it appears that cpphs' current LGPL+SLE licensing doesn't pose an *objective* showstopper problem but is rather more of an inconvenience as it causes argumentation/discussion overhead (which then /may/ actually result in Haskell being turned down eventually over alternatives that do without LGPL components). In order to acknowledge this discomfort, for GHC 7.12 we propose to follow "plan 4" according to [1] (i.e. calling out to a cpphs-executable as a separate process), thereby avoiding pulling any LGPL-subjected cpphs code into produced executables when linking against the 'ghc' package. "Plan 2" (i.e. embedding/linking cpphs' code directly into ghc) would reduce fork/exec overhead, which can be substantial on Windows [2], but plan 4 is no worse than what we have now. Last Call: Are there any objections with GHC adopting "plan 4"[1]? [1]: https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp [2]: http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/8869 Thanks, HVR On 2015-05-06 at 13:08:03 +0200, Herbert Valerio Riedel wrote:

...

Hello *,

As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor.

This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page

https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out).

So please go ahead and read the Wiki page... and then speak your mind!

Thanks, HVR

[1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics?

-- "Elegance is not optional" -- Richard O'Keefe

Simon Marlow

19 Jun 19 Jun

2:48 p.m.

New subject: Native -XCPP Conclusion

I have no problem with plan 4. However, I'll point out that implementing CPP is not *that* hard... :) Cheers, Simon On 18/06/2015 09:32, Herbert Valerio Riedel wrote:

...

Hello *,

Following up on the "Native -XCPP" Proposal discussion, it appears that cpphs' current LGPL+SLE licensing doesn't pose an *objective* showstopper problem but is rather more of an inconvenience as it causes argumentation/discussion overhead (which then /may/ actually result in Haskell being turned down eventually over alternatives that do without LGPL components).

In order to acknowledge this discomfort, for GHC 7.12 we propose to follow "plan 4" according to [1] (i.e. calling out to a cpphs-executable as a separate process), thereby avoiding pulling any LGPL-subjected cpphs code into produced executables when linking against the 'ghc' package.

"Plan 2" (i.e. embedding/linking cpphs' code directly into ghc) would reduce fork/exec overhead, which can be substantial on Windows [2], but plan 4 is no worse than what we have now.

Last Call: Are there any objections with GHC adopting "plan 4"[1]?

[1]: https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

[2]: http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/8869

Thanks, HVR

On 2015-05-06 at 13:08:03 +0200, Herbert Valerio Riedel wrote:

...
Hello *,

As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor.

This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page

https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out).

So please go ahead and read the Wiki page... and then speak your mind!

Thanks, HVR

[1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics?

3623

Age (days ago)

3667

Last active (days ago)

List overview

Download

14 comments

11 participants

participants (11)

Andrés Sicard-Ramírez
Austin Seipp
Brandon Allbery
Herbert Valerio Riedel
Herbert Valerio Riedel
Jan Stolarek
Karel Gardas
Malcolm Wallace
Mikhail Glushenkov
Simon Marlow
Stephen Paul Weber