[Haskell-cafe] A restricted subset of CPP included in a revision of Haskell 98

[Lennart Augustsson]

Even though I'm largely responsible for making CPP available in a  
Haskell compiler I think it's an abomination.  It should be avoided.
If we standardize it, people will use it even more.  I think we  
should discourage it instead, then looking at exactly what it's used  
for and supplying sane versions of it.

	-- Lennart

On Aug 17, 2006, at 12:44 , Brian Smith wrote:

> Hi,
>
> I find it strange that right now almost every Haskell program  
> directly or indirectly (through FPTOOLS) depends on CPP, yet there  
> is no effort to replace CPP with something better or standardize  
> its usage in Haskell. According to the following document, and my  
> own limited experience in reading Haskell code, CPP is the most  
> frequently used extension:
>     http://hackage.haskell.org/trac/haskell-prime/wiki/ 
> HaskellExtensions
> I think that if we accepted that CPP was part of the language, we  
> could then place some restrictions on its use to facilitate easier  
> parsing. Here are some suggestions, off the top of my head:
>
> * #define can only be used for parameterless definitions
> * #define'd symbols are only visible to the preprocessor
> * #define can only give a symbol a value that is a valid  
> preprocessor expression
> * #define can only appear above the module declaration
> * a preprocessor symbol, once defined, cannot be undefined or  
> redefined
> * #include and #undef are prohibited
> * The preprocessor can only be used at the top level. In  
> particular, a prepropcessor conditional, #error, #warn, #line would  
> not be allowed within the export list or within a top-level binding.
> * A Haskell program must assume that any top-level symbol  
> definitions are constant over the entire program. For example, a  
> program must not depend on having one module compiled with one set  
> of command-line preprocessor symbol bindings and another module  
> defined with a different set of bindings.
> * preprocessor directives must obey Haskell's layout rules. For  
> example, an #if cannot be indented more than the bindings it contains.
>
> The result would be:
> * Syntax can be fully checked without knowing the values of any  
> preprocessor symbols.
> * Preprocessor syntax can be added easily to a Haskell parser's BNF  
> description of Haskell.
> * No tool will need to support per-file/module preprocessor symbol  
> bindings.
>
> Again, all this is just off the top of my head. I am curious about  
> what problems these restrictions might cause, especially for  
> existing programs. I know that GHC itself uses some features that  
> would be prohibited here. But, GHC is really difficult for tools to  
> handle even with these restrictions on its source code. For now, I  
> am more interested in the libraries in FPTOOLS and users' programs.  
> What libraries/programs cannot easily be reorganizated to meet  
> these restrictions? I suspect "#define'd symbols are only visible  
> to the preprocessor" would be the most troublesome one.
>
> Thanks,
> Brian
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe