[Haskell-cafe] Current status of Mavericks CPP

[Ben Franksen]

Brandon Allbery wrote:
> On Wed, Apr 16, 2014 at 2:42 AM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:
>> >> If ghc-clang-wrapper causes problems with your code, I'd suggest to
>> >> fix your code. I'm not sure this actually happens.
>> >
>> > It does. See my previous messages. Haskell is not C, and some Haskell
>> > constructs simply will not work with a program that must lex (and, for
>> > ANSI, parse) C code.
>>
>> I agree that ghc-clang-wrapper can cause problems and GHC should
>> provide its own CPP. But have you ever experienced such problems
>> actually?
>>
> 
> I personally have not, but that's largely because I haven't really ever
> needed to use -XCPP. I did earlier today talk with someone on IRC who was
> running into one lexical incompatibility (Haskell's allowing ' to be an
> identifier character), and have in the past helped diagnose issues with
> the clang wrapper not working with some programs on Hackage which are
> incompatible with ANSI C (that ' issue, plus the use of # and ##).
> 
> And I consider it nonsensical that people who need to use -XCPP to deal
> with different library versions or language extensions are restricted to
> that subset of Haskell which is lexically compatible with C. The problem
> here is not those people's code; it is that we are relying on a tool which
> by its nature lexes C code, and using it on Haskell code.

I couldn't agree more. My experience in this area is very bad. I am 
maintaining a language that is very C-like (it has *almost* the same lexical 
syntax), and still I regularly encounter problems when CPP is used as a 
preprocessor for it, due to sudden changes that are made e.g. by the GNU 
folks that are compatible with C but not other languages.

Furthermore, I strongly suggest that a suitable replacement for CPP should 
be designed in such a way that its specification can be added to a future 
Haskell language standard. This is the only way to ensure that 
implementations other than GHC can be brought along.

Has nobody ever written a paper about how to extend Haskell with the few 
features we actually need from CPP? I think general macro replacement like 
CPP offers is not on the list, right? IIUC, CPP is used in Haskell libraries 
almost exclusively for conditional compilation. I think the syntax should be 
based on pragmas, like in

{-# DEFINE WITH_FEATURE_X True #-}

{-# IF WITH_FEATURE_X && GHC_VERSION >= 708 && GHC_VERSION < 712 #-}
...
{-# ELSIF <some other condition> #-}
...
{-# ENDIF #-}

That's four new pragmas (IF, ELSIF, ENDIF, DEFINE). Expressions (in DEFINE, 
IF and ELSIF) must have type Bool (True, False) or Integer (decimal notation 
only), identifiers must be ASCII (letter, followed by any amount of '_' or 
letter or decimal). Writing an evaluator for such expressions is an exercise 
for beginners.

There is no need for such a CPP-replacement to be able to parse (nor even 
lex) all of Haskell; it just needs to understand lexing of Haskell string 
literals (so a pramga inside a string literal gets ignored) and comments. 
(Hmm, what about TH splices?) Existing Haskell implementations like GHC are 
of course free to integrate the preprocessing stage with normal compilation, 
making implementation even simpler.

It's all very simple and nicely integrated. It would even be possible to 
write a tool that automatically converts existing Haskell modules that now 
use CPP directives to the new style (assuming the above is really the subset 
of CPP features that is actually used in practice).

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." -- Scott Adams