#ifdef considered harmful (was: DData)

Graham Klyne GK at ninebynine.org
Tue Apr 6 11:39:17 EDT 2004


Please, no #ifdef's in standard library code!

Dealing with these on Windows systems (for which there is no out-of-the-box 
CPP) has been one of my messiest problems with existing (non-standard) 
library, figuring out how to set up the necessary environment to create the 
symbol definitions required and then to ensure the code is properly 
processed, etc.

Worse, when the standard library code contains #ifdefs, it makes it even 
more difficult to write applications using such libraries that are easily 
distributed and used by non-Haskell programmers.  Asking a user to install 
a Haskell run-time is one thing, but requiring them to figure out how to 
get all the libraries to compile can be a major barrier to adoption.

...

So that's my plea.  What to do about it?  Some thoughts:

(a) where possible, use "run-time" tests rather than "compile-time" code 
selection.  If the conditions are constant True or False, surely a compiler 
should be able to eliminate the redundant code?

(b) one place where the above cannot work is where different module imports 
are required on different systems.  I don't have a ready answer, but maybe 
one is to work to eliminate spurious differences between systems (I think 
the library infrastructure project may help here).

(c) another problem area is where type definitions (incl. function 
interfaces)  differ between systems.  Again, eliminating spurious 
differences would help.

(d) For those differences that cannot be eliminated implementing (in 
Haskell) a portable preprocessor that can ship as part of every Haskell 
environment?

(e) Where #ifdefs really are needed, work to confine them to a very small 
number of modules, rather than scattering them throughout some code.  In 
this way, where necessary, a manual edit of the file becomes a feasible 
proposition.   For example, this could be done for differing imports, and 
in many cases could be done for differing type declarations.

In the long run, I thing the goal should be to aim for a standard run-time 
platform that is common across all "standard" Haskell systems, which is 
simply used by add-on library code.  With a very few exceptional functions, 
languages such as Python and Java achieve this very well.

#g
--

At 16:51 05/04/04 +0200, you wrote:
>Just a small remark: The DData modules are all marked as "portable", which
>is not entirely correct, because they import Data.Monoid, which is not
>portable. A possible solution/workaround for this would be wrapping these
>Monoid instances into #ifdefs, depending on the Haskell system in question.
>If I see this correctly, this would only be an issue for Hugs in Haskell98
>mode, but the API can't depend on command line flags. Hmmm, not very nice.
>Better suggestions appreciated...
>
>Cheers,
>    S.
>
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact



More information about the Libraries mailing list