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.   <div>
<br></div><div>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<span></span></div><div><br>On Friday, February 21, 2014, Roman Cheplyaka <<a href="mailto:roma@ro-che.info">roma@ro-che.info</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Update: that type-eq uses cpphs is its own preference, encoded in its<br>
.cabal file. That means the impact of this bug is lower than I assumed.<br>
<br>
Can someone comment on the plans to use cpphs in ghc? I jumped to a<br>
conclusion that this has already happened, but I definitely remember<br>
that it was discussed. What was the conclusion?<br>
<br>
* Roman Cheplyaka <<a href="javascript:;" onclick="_e(event, 'cvml', 'roma@ro-che.info')">roma@ro-che.info</a>> [2014-02-21 18:04:17+0200]<br>
> Hi Malcolm,<br>
><br>
> This appears to be a cpphs bug. For the following code<br>
><br>
>     #define x (1 == 1)<br>
>     #if x<br>
>     YES<br>
>     #else<br>
>     NO<br>
>     #endif<br>
><br>
> cpphs 1.18.1 prints NO, while the expected output (and the output GNU<br>
> cpp produces) is YES. If parentheses around 1 == 1 are removed, or if x<br>
> is inlined manually, then cpphs correctly prints YES.<br>
><br>
> This affects GHC 7.8 users in a serious way: GHC 7.8 uses cpphs, and the<br>
> above code is a simplified version of macros generated by cabal.<br>
><br>
> For this reason, for instance, type-eq 0.4.1 cannot be build by GHC 7.8<br>
> RC1, despite the proper CPP guards.<br>
><br>
> Roman<br>
</blockquote></div>