Il giorno 06/mag/2015, alle ore 23:07, Sven Panne
More seriously: We don't want to break hundreds of packages on Hackage, the only thing we really need is a well-defined CPP-like preprocessor, so integrating e.g. cpphs somehow seems to be the right way IMHO. If it's not cpphs, I wouldn't mind, the main point is that it's the same on all platforms and handles basically *all* things CPP can.
Hi all, 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? Then why don't you _import_ the clang's preprocessor into GHC source tree and use that? 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). Greetings, Nicola