Re: [Haskell-cafe] Current status of Mavericks CPP

So if I'm reading this all correctly: 1. Package authors are *not* encouraged to change their code to try and work around this issue. 2. Medium/long term, this won't be a problem at all due to changes in GHC itself. 3. Short term, users need to follow the instructions at [1] if they're using GHC 7.6 (or earlier?). [1] http://www.haskell.org/platform/mac.html On Wed, Apr 16, 2014 at 9:25 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

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 wrote:

...

On Wed, Apr 16, 2014 at 2:05 AM, Michael Snoyman 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