#ifdef considered harmful (was: DData)
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
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
(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.
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...
>Libraries mailing list
>Libraries at haskell.org
More information about the Libraries