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