On 2015-05-06 at 17:36:05 +0200, Stephen Paul Weber wrote:
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.
Yes. This is one of my favourite things in GHC-land -- that an existing, good-enough, standardised, and widely-deployed solution was chosen over a NiH reinvention of preprocessing. This allows other Haskell compilers to support CPP on basically any system (since cpp is so standard) without much effort, or even if the compiler does not support {-# LANGUAGE CPP -#} the user can easily run `cpp` over the source files themselves before feeding the source into the compiler.
Because it is a real `cpp` being used, the developmer must take care to follow the CPP syntax in the file that will then be transformed into Haskell by `cpp` in the same way that C, C++, and other developers have to take extra care (especially around use of # and end-of-line \) when using `cpp`, but this is the normal state of affairs for a secondary preprocessor step. As a benefit, the source code will be processable by standard `cpp` implementations available for virtually every platform.
In short, the current solution provides a very robust and portable way to do pre-compile preprocessing, and I like it very much.
The problem I have with that line of argument is that we're using the so-called 'traditional mode' of `cpp`[1] for which afaik there is no written down common specification different implementations commit to adhere to (well, that's because 'traditional mode' refers to some vague implementation-specific "pre-standard" cpp semantics). And how is the developer supposed to take care to follow the (traditional mode) CPP syntax, if he can't test it easily with all potentially used (traditional-mode) `cpp`s out there? This already has led to problems with Clang's cpp vs GCC's cpp. Moreover, I was under the impression that it's only a matter of time till `traditional mode` support may be dropped from C compiler toolchains. Otoh, we can't use an ISO C spec conforming c-preprocessor, as that would conflict even more heavily w/ Haskell's grammar to the point of being inpractical. [1]: https://gcc.gnu.org/onlinedocs/cpp/Traditional-Mode.html