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@haskell.org http://www.haskell.org/mailman/listinfo/libraries
------------ Graham Klyne For email: http://www.ninebynine.org/#Contact