There's actually quite a bit of hacking to make ghc properly support decoupling the Haskell cpp and c compiler. Nothing has been merged in yet. I've some (incomplete) patches with the help of a few other folks, and Austin might be doing some exploratory also.
The engineering needed to support cpphs is also exactly what's needed to make the Haskell cpp choice easy to change in the ghc settings files etc
On Friday, February 21, 2014, Roman Cheplyaka <
roma@ro-che.info> wrote:
Update: that type-eq uses cpphs is its own preference, encoded in its
.cabal file. That means the impact of this bug is lower than I assumed.
Can someone comment on the plans to use cpphs in ghc? I jumped to a
conclusion that this has already happened, but I definitely remember
that it was discussed. What was the conclusion?
* Roman Cheplyaka <roma@ro-che.info> [2014-02-21 18:04:17+0200]
> Hi Malcolm,
>
> This appears to be a cpphs bug. For the following code
>
> #define x (1 == 1)
> #if x
> YES
> #else
> NO
> #endif
>
> cpphs 1.18.1 prints NO, while the expected output (and the output GNU
> cpp produces) is YES. If parentheses around 1 == 1 are removed, or if x
> is inlined manually, then cpphs correctly prints YES.
>
> This affects GHC 7.8 users in a serious way: GHC 7.8 uses cpphs, and the
> above code is a simplified version of macros generated by cabal.
>
> For this reason, for instance, type-eq 0.4.1 cannot be build by GHC 7.8
> RC1, despite the proper CPP guards.
>
> Roman