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?