#ifdef considered harmful (was: DData)
GK at ninebynine.org
Tue Apr 6 18:10:14 EDT 2004
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
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
>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?
More information about the Libraries