#ifdef considered harmful (was: DData)

[Sven Panne]

Robert Will wrote:
> 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.

Well, I hate to repeat myself, but this oversimplifies things a bit and
ignores the fact that macros are quite useful as a syntactic abstraction,
see one of my previous posts. One of the main goals in writing good SW
is avoiding redundancy, and if the language in question doesn't allow us
to abstract what we want to do several times, let's use macros! It's
infinitely better than using cut-n-paste with slight variations.

The real question should be what preprocessor to use. Admittedly, CPP is
not ideal for Haskell, because it's totally unaware of the language it is
processing, has no mechanisms for hygienic macros (see, e.g. Scheme), etc.
Template Haskell might be a better choice, but only if one doesn't care
about portability between different Haskell systems.

> [...] 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.

Again, this is a valid argument for toy programs/libraries, but there are
cases where this is particularly bad: I definitely won't duplicate hundreds
of "foreign imports", just because WinDoze DLLs have a different calling
convention C. This would be a maintenance nightmare.

> [...] So please no preprocessing in any code!

A more realistic plea would be: As little preprocessing as possible in a
few selected places!

Cheers,
    S.