[Haskell-cafe] RFC: "Native -XCPP" Proposal

[Herbert Valerio Riedel]

On 2015-05-07 at 08:42:52 +0200, Nicola Gigante wrote:

[...]

>> More seriously: We don't want to break hundreds of packages on
>> Hackage

[...]

> I'm following the discussion from the outside but I'm wondering if you have considered the following idea.
>
> From what I understand the current problem with using the 
> system's cpp is inconsistency between different compilers, is 
> it?

Yes... and historically, large amounts of *existing* code on Hackage
were written against GCC cpp's traditional-mode, and when Apple pushed a
large amount of users/developers to use the Clang toolchain, packages
started becoming compatible w/ Clang's cpp

(and for the record, Clang-cpp's lack of a "proper" traditional-mode has
not only caused problems for GHC, see
e.g. https://wiki.freebsd.org/PortsAndClang/CppIssues)

> Then why don't you _import_ the clang's preprocessor into 
> GHC source tree and use that?

That's an interesting thought. I've added your suggestion to the wiki
proposal-page as a sub-variant of "plan 1" (or does it rather constitute
a new plan of its own?)

However, without effectively convincing clang's cpp implementation to
emulate more of gcc's -traditional mode, this would most likely break
old package versions available on Hackage that still work perfectly fine
now w/ gcc-cpp (but not clang-cpp), as clang-cpp divergence from gcc-cpp
(which was till then the defacto-standard for how -XCPP was expected to
behave) is the reason we're having this discussion now in the first
place.

> As you probably know clang is not only a compiler, but a set of
> libraries to handle C/C++ code. AFAIK linking only the lexer module
> (which is responsible for the preprocessor) and its direct
> dependencies, which at the end amount to libLLVMCore and the C++
> standard library, shouldn't be too much size overhead (ymmv). The
> license is also ok, since it's a BSD-something.
>
> To also address the issue of how the preprocessor handles 
> Haskell tokens in macros, if you import the source someone 
> could make a patch to add an option to make the 
> preprocessor less strict (but I'm sure to have seen already 
> something to opt for a lax semantics when the preprocessor is 
> used standalone, need to check that). If done well and 
> promised to be maintained, I think the patch could also be 
> accepted mainstream (it's not the first time an LLVM project 
> accepts GHC specific patches, see the support for its call 
> convention in the code generator).

Personally, I'm much more motivated to work on improving Haskell-code
than to maintain a 3rd party C/C++-based preprocessor component. So I'm
afraid that unless we find this "someone" who is willing to provide the
willpower and time to bend Clang's preprocessor library to GHC's needs
(which foremost would mean to maximize compatibility w/ *existing* code
on Hackage using -XCPP, assuming that's a good heuristic for also
maximizing compatibility w/ code *not* on Hackage)

And judging from past discussions such as

  http://comments.gmane.org/gmane.comp.compilers.clang.scm/67381

I'm skeptical that Clang's cpp (whose token-based parsing seems to be in
conflict with character-based parsing which is more suited for
traditional-mode non-C semantics)

Cheers,
  hvr