Re: #ifdef considered harmful (was: DData)

At 16:12 06/04/04 +0100, Malcolm Wallace wrote:

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.

I guess it's the community's choice of what is important, but in my experience this is a major impediment to distributing portable programs written in Haskell for use by non-Haskellite end users.

...

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

There should be no externally visible type differences in standard libraries. But internal to the library, different systems might indeed use different representations. For an optimising compiler like GHC this is really important, since certain extensions are a big help, but simpler systems like Hugs and nhc98 still need a viable Haskell'98 representation if possible.

So I would hope, but I seem to recall coming across some variations of function parameters between systems. I don't remember where. I'm less concerned by the internal workings of a particular Haskell platform, just what's presented to an application program.

...

(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.

Sigh! It seems perverse that a high-level programming system like Haskell remains dependent on age-old assembler-programming techniques. But if so be it...

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.

Me too, I guess. But there is a second prong to this issue: where to the symbol definitions used to control the preprocessor come *from*? Or is that also addressed by the hmake code? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact