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