RFC: "Native -XCPP" Proposal

[Brandon Allbery]

On Wed, May 6, 2015 at 11:36 AM, Stephen Paul Weber <
singpolyma at singpolyma.net> wrote:

> 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


I have to assume my irony detector is broken as well. Or maybe I should
just assume that "all the world's Linux with gcc" is assumed to be forever
true and forever reliable by "all right-thinking people" so let's just
sweep the nonissue under the rug because it can oh so obviously never be a
real issue....

Because I had to face this back a couple decades ago, when my employer
ported an application written in a 4GL (database language) to SCO Unix. The
4GL assumed cpp was the ever reliable pcc one and broke very badly when SCO
used one integrated into its lexer (making it even more tightly wedded to C
syntax than clang's). Eventually we replaced its cpp with a wrapper that
ran m4 and redid everything else in m4's syntax.

Which is why I was always a bit worried about ghc relying on cpp, was
unsurprised when clang caused issues, and am rather annoyed that there are
people who believe that they can just ignore it because REAL users will
always be on Linux with gcc and all them furriners using weird OSes like OS
X and FreeBSD can safely be ignored with their
not-the-One-True-OS-and-compiler platforms.

Additional historical note that I assume True Believers will ignore as
meaningless: X11 used to make the same assumption that cpp was always and
forever guaranteed to be friendly to non-C and this still shows at times in
things like xrdb resource databases. They did accept the inevitable and
(mostly) stop abusing it that way, and are now moving away from imake which
likewise assumes it's safe to use cpp on Makefiles. (And yes, I encounter
the same inability to comprehend or accept change there.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150506/6d11e7f3/attachment-0001.html>