Henning Thielemann wrote:
> On Thu, 17 Aug 2006, Brian Smith wrote:
>
>> 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.
>
> I think there should be more effort to avoid CPP completely.

I agree, especially as I'm trying to write an editor for Haskell which will
certainly not cope with CPP at all! ;-)

I agree with this sentiment. But, CPP also has some advantages over the other suggestions presented here. Using CPP, we can create libraries that work with GHC 5.x and old versions of Hugs. If an alternative to CPP were chosen, would we update fptools to use this alternative? If it involves new syntax, then updating FPTOOLS to use the new syntax would break backward compatibility. And, if (the vast majority of) FPTOOLS does not use the solution then it is not useful.

The reason it would not cope is that CPP turns what would otherwise be one
program/module/library into several programs/modules/libraries which
simultaneously co-exist in the same text in a rather uneasy and vague
relationship, and what's even worse: the same module can have multiple
meanings in the *same* program depending on use of #ifdef #undef etc, thus
making code navigation quite impossible: the meaning of each module now
depends on how you got there and might even be different the second time
round...

Notice that with my suggestions none of these problems apply, because all external "command line" parameters have a single static value over the whole program (two modules cannot depend on differing values of a single macro, #undef is not allowed). Changing the bindings for these macros would invalidate any cached information the editor has. But, the editor has to support updating its caches anyway, to deal with switching libraries in/out, etc.

I won't use an IDE effectively if it can't handle the libraries in FPTOOLS, which liberally use the preprocessor. Either the IDE has to handle the preprocessor or the libraries have to stop using them, or they have to meet somewhere in the middle.

I think the acid test would be to reach a point where anyone can download
the source for some large program such as GHC and just type ghc --make Main
and expect the program to be built in one pass with no problems.

I agree with this sentiment as well. Most of the little data processing programs I have written are built exactly like that already. How can we get the existing libraries to build like that though?

- Brian