Preprocessors

[Henrik Nilsson]

Hi all,

Sven Panne wrote:

> Furthermore, I don't think that the "C" in CPP is a real problem, at 
> least in
> the traditional mode. 99% of the uses of a preprocessor for Haskell was 
> simply
> for ironing out some platform/implementation differences, nothing very 
> elaborate.

I guess we're straying away from the original topic.

The question here is not how elaborate things one is trying to do
with a CPP-like preprocessor. The question is if a Haskell source file
gets passed through CPP at all, and if so, to what extent the
preprocessor is able to cope with Haskell identifiers, string and
character constants, comments, etc.

> So we don't really need a Haskell-aware preprocessor, just something which
> doesn't stumble over common Haskell constructs and behaves consistently.
> 

Of course one can argue that the problem isn't that bad. After all, 
people have managed to use CPP for very serious work for years.

But clearly the situation is not ideal. Try using the perfectly
legal Haskell operator /* in some code that gets fed through CPP, for
example. (I, involuntary, did try! ;-) And for another example, why
shouldn't one use Haskell's feature for string gaps? They are certainly
useful from time to time to layout code neatly.

The bottom line is that as long as code is syntactically legal Haskell,
one should not have to worry if all constructs in the source file falls
into the subset of "common" Haskell constructs, whatever that is.

So, coming back to Cabal, that's why I think it at least should be easy
to somehow specify selective preprocessing. Be it by some kind of file
extension, which seems resonable to me, or by some form of option
pragma in the text of the source file.

I care about these things mainly because I have had problems with CPP
and Haskell in practice, and we even went to quite great lengths in the
Yale build system (mainly used for Yampa, but it was supposed to be of
general use) to ameliorate the problem of having to rely on C-centric
preprocessing for Haskell code by making selective preprocessing easy.
(As an added bonus, there's also a small performance benefit of CPP-ing
only what's necessary.)

However, ultimately I still think the right solution is a preprocessor
that does understand Haskell's lexical syntax. I agree that it could
be like CPP in all other ways, and thus mainly suitable for doing
"not very elaborate" things. In fact, it would probbaly be a good
thing if it only was suitable for doing very simple things.

Best regards,

/Henrik

-- 
Henrik Nilsson
School of Computer Science and Information Technology
The University of Nottingham
nhn at cs.nott.ac.uk

This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks.  Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.