Hi,<br><br>
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:<br>
&nbsp;&nbsp;&nbsp; <a href="http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions">http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions</a><br>
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:<br><br>* #define can only be used for parameterless definitions<br>* #define'd symbols are only visible to the preprocessor
<br>* #define can only give a symbol a value that is a valid preprocessor expression<br>* #define can only appear above the module declaration<br>* a preprocessor symbol, once defined, cannot be undefined or redefined<br>
* #include and #undef are prohibited<br>* 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.
<br>* 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.
<br>* preprocessor directives must obey Haskell's layout rules. For example, an #if cannot be indented more than the bindings it contains.<br><br>The result would be:<br>* Syntax can be fully checked without knowing the values of any preprocessor symbols.
<br>* Preprocessor syntax can be added easily to a Haskell parser's BNF description of Haskell.<br>* No tool will need to support per-file/module preprocessor symbol bindings.<br><br>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 &quot;#define'd symbols are only visible to the preprocessor&quot; would be the most troublesome one. 
<br><br>Thanks,<br>Brian<br>