state of the cabal (preprocessors)

Henrik Nilsson nhn at Cs.Nott.AC.UK
Wed Oct 20 10:07:05 EDT 2004


Hi all,

Simon Marlow wrote:

> While consistency is a good thing, in this case I'm not convinced.
> Converting all my .hs files to .hs.cpp is going to be really painful.
> Plus it's not really a compiler-independent CPP phase because of the
> preprocessor symbols injected by the compiler.
> 
> I think a special case for CPP is in order, because (at least in my
> experience) a lot of Haskell is CPP'd.  All of GHC and most of the
> libraries are CPP'd for example.  
> 
> So I'd be happy if Cabal had a package-wide CPP flag.  That is, with the
> flag on, all .hs and .lhs files in the package are CPP'd.  Think of it
> as a flag that affects the language, in the same way that we turn on
> various Haskell extensions via flags (I know the analogy isn't perfect).

Well, one thing does not necessarily exclude the other. One could have
such a flag for backwards-compatibility reasons and for the case where
everything REALLY needs to be be CPP-ed, but encourage programmers
to minimize the need for CPP-ing to as few files as possible, and
indicate those files by some convention such as an extension.

> If you want per-file granularity, then a directive in the Haskell file
> would be fine.  GHC currently uses {-# OPTIONS -cpp #-}, but I'd be
> happy to implement a different syntax.

Yes, a reasonable approach as long as all Haskell compilers
understand this convention. Indeed, it has certain advantages,
and in general I agree that it is nice if file-specific options
are given in the file in question.

[Aside: Is there a general agreement that the OPTION pragma should
be understood by all Haskell systems, whereas system-specific
options are given by pragmas like OPTIONS-GHC, OPTIONS-NHC, etc.
or something along those lines?]

But what about interpreters? Would it be
the build-system's responsibility (be it Cabal's simple build system
or a make based system called from Cabal or whatever) to look for
options pragmas in the source and run CPP if neccessary on those files?

If so, at least for make-based systems, a scheme based on file
extensions is probably easier to handle?

If not, then it would seem that non-preprocessed sources do get
installed, and that Hugs would have to look for the option pragma
on a per file bases and run CPP if necessary before loading the source?
Perfectly OK, except that I still think it is a good idea to preprocess
only once.

Finally, does not the option pragma solution imply that CPP-ing always
is the last preprocessing step?

This might be a reasonable assumption, but at least Malcolm raised
concerns about building such an assumption into the tools.

Best,

/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.



More information about the Libraries mailing list