Further more, once some patches I've cooked up land in 7.8.3, it will be possible to ship ghc with it's own cpp program (or use GCC or clang cpp)
  
Austin's 7.8.2 mavericks build will correctly handle / cope with clangs cpp, but there's a clear concensus to evolve Haskell cpp tooling going forward to avoid these issues in the future 

For those on ghc 7.6 or earlier who can't upgrade to ghc 7.8, the work arounds listed on the platform site are the current options. 



On Wednesday, April 16, 2014, Brandon Allbery <allbery.b@gmail.com> wrote:
On Wed, Apr 16, 2014 at 2:05 AM, Michael Snoyman <michael@snoyman.com> wrote:
I still seem to be getting bug reports about the CPP implementation of Mavericks. Last I'd heard, it seemed that general consensus was that packages should *not* be patched to work around the different CPP implementation, and instead Mavericks users should be installing GCC's CPP.

Is this accurate? And is there a wiki page somewhere describing the situation and how to work around it? I'd like to have some authoritative URL to point people to, especially given that I have no access to a Mac system and therefore can't test this myself.

The correct answer is for ghc 7.8 to become established, because it removes the dependency on an external C preprocessor. Some of the reasons for this are:

- with FreeBSD 10 having moved to clang on x86 / x86_64, it is clearly only a matter of time before this becomes more than just a "Mavericks" issue;

- pretty much everyone *except* the Haskell community accepted that expecting cpp to handle anything other than C and derivatives was a mistake back when ANSI C came out;

- even with a K&R-style cpp like gcc -traditional, there are Haskell constructs that can break it; consider that it must know how to parse strings (there are some subtle differences between Haskell and C string syntax) and char constants (did you know that C allows multi-character (char) constants? and pretty much always has?) in order to know when to expand macros. With an ANSI cpp like clang's, it must also know when to interpret # and ## as splices.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net