SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal
gale at sefer.org
Thu May 21 12:09:13 UTC 2015
>> ...I thought that the idea was that we wanted
>> it actually integrated into GHC.
Herbert Valerio Riedel wrote:
> That would be the preferred way from a technical standpoint, as it would
> avoid fork/exec and make it easier to integrate the CPP-phase tighter
> into the lexer/parser.
> However, due to the, sadly, mostly non-technical issues brought up, it
> seems to me that isolating cpphs into a separate process (w/ the option
> to configure GHC to use some other cpp implementation at your own risk
> if you need to avoid the cpphs implementation at all costs) would be the
> compromise acceptable to everyone in the short run while addressing the
> primary goal to decouple the default-configuration of GHC from the
> fragile system-cpp semantics.
Correct me if I'm wrong:
GHC already supports using an external CPP processor
as an option. And cpphs is already easily buildable as
a stand-alone external CPP processor compatible with
So can't we incorporate cpphs into GHC as is, but
also provide a build option to exclude it from a GHC
build? In a non-cpphs build, CPP would only work
if an external processor is provided.
That's even better than the GMP situation - it really
would be simple and practical to create and use
a non-cpphs GHC if needed. As opposed to a non-GMP
build, which in reality is only a theoretical possibility
to satisfy the lawyers.
More information about the ghc-devs