#ifdef considered harmful (was: DData)

[Robert Will]

Am Dienstag, 6. April 2004 11:39 schrieb Graham Klyne:
> Please, no #ifdef's in standard library code!

At 16:56 06/04/04 +0200, Wolfgang Jeltsch wrote:
> You need them if you want you use deriving clauses and Haddock at the
> same time, since Haddock doesn't fully understand deriving.

On Tue, 6 Apr 2004, Graham Klyne wrote:
> This particular example gives me a certain tail-wags-dog feeling...

Yes, apart from the use in Macros and such, preprocessing is really a
workaround for problems that should not be there.  That's why every new
programming language comes without a preprocessor, but after some time
when incompatibilities arise, a preprocessor appears.  That's because
programmers tend to do a "local fix" instead of eliminate the root
problem, that is, incompatibilities between systems.

The problem is, that the preprocessor does make things more complicated,
not only for the programmer/user, but also for other applications that
work with the code: how should they be treated by a documentation
generator, by a refactoring tool, by testing tools, and so on?

I think what Haskellers (and others) can do in most cases is to factor out
platform dependent parts to mini-modules which have different
implementations but the same interface.  The version of such a module is
choosen by the path it resides in during the build process.  (Simplest
case: the -i option of the compiler.)  This also has the advantage, that
the dependencies are made explicit, while preprocessing is a very implicit
technique, e.g. you have to check type and even syntactic correctness of
each possible version separately.

For example (for JP!) the #ifdefs in DData could nicely be factored away
with this, and we could even have all the bitfiddling code in one module,
eliminating redundancy between Maps and Sets...

So please no preprocessing in any code!

Robert