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

[Brian Smith]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/haskell-cafe/attachments/20060817/5dab06a9/attachment.htm