#ifdef considered harmful (was: DData)

[Graham Klyne]

At 16:12 06/04/04 +0100, Malcolm Wallace wrote:
>Graham Klyne <GK at ninebynine.org> 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