Re: #ifdef considered harmful

Malcolm Wallace writes:

Graham Klyne writes:

...

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

:)

Much as we all hate cpp, I'm afraid the standard libraries are already heavily littered with #ifdefs. Getting rid of them is basically impossible.

Perhaps we can work to slowly phase them out or confine them?

...

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

I think this is ultimately going to be the most viable solution. Let's write a simple 'hspp' (in Haskell?) that is backward compatible with 'cpp -traditional' (although we might also design a newer nicer syntax too), and distribute it with every compiler. It can't be too difficult, surely? Half of the cpp parsing/selection code is already available within hmake. I would take on the project myself, if I had time.

I agree that this should be possible with the hmake code. FWIW, I have, in fact, already teased that functionality out (to a small degree) and made it available in my work-in-progress HMake API. I expect that there would be a function Distribution.Build.cpp and needsCpp which are implemented in my HMake.hs code thusly:

-- |Does the source code represented by this string require C -- pre-processing? needsCpp :: String -> Bool needsCpp = GetDep.needsCpp

-- |Return just the list of lines that the real cpp would decide to keep. cpp :: FilePath -> SymTab String -> KeepState -> [String] -> [String] cpp = Imports.cpp

Eww, that cpp maybe uses unsafePerformIO? I can't remmeber. Anyway, if that's true, it's something we can fix. Graham is, of course, right that populating the SymTab now becomes the problem. I did write a little function to make this easier:

-- |Convert the environment to a SymTab. Don't know if this is -- actually useful, but it may simplify interface to cpp. envToSymTab :: [(String, String)] -- ^Environment -> SymTab String envToSymTab = foldr insertST emptyST

Anyway, take that for what it's worth. The HMake code is nice & clean, for the most part, and I'm working to refactor it to make its various bits of functionality available outside the executable itself. I plan to update this list on what I'm busy with on the LIP stuff Real Soon Now :) peace, isaac