RFC: "Native -XCPP" Proposal

[Herbert Valerio Riedel]

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