Native -XCPP Conclusion

[Simon Marlow]

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