Fwd: [Haskell-cafe] A restricted subset of CPP included in a revisionof Haskell 98

[Brian Smith]

On 8/20/06, Brian Hulley <brianh at metamilk.com> wrote:

> Henning Thielemann wrote:
> > On Thu, 17 Aug 2006, Brian Smith wrote:
> >
> >> I find it strange that right now almost every Haskell program
> >> directly or indirectly (through FPTOOLS) depends on CPP, yet there
> >> is no effort to replace CPP with something better or standardize its
> >> usage in Haskell.
> >
> > I think there should be more effort to avoid CPP completely.
>
> I agree, especially as I'm trying to write an editor for Haskell which
> will
> certainly not cope with CPP at all! ;-)


I agree with this sentiment. But, CPP also has some advantages over the
other suggestions presented here. Using CPP, we can create libraries that
work with GHC 5.x and old versions of Hugs. If an alternative to CPP were
chosen, would we update fptools to use this alternative? If it involves new
syntax, then updating FPTOOLS to use the new syntax would break backward
compatibility. And, if (the vast majority of) FPTOOLS does not use the
solution then it is not useful.


The reason it would not cope is that CPP turns what would otherwise be one
> program/module/library into several programs/modules/libraries which
> simultaneously co-exist in the same text in a rather uneasy and vague
> relationship, and what's even worse: the same module can have multiple
> meanings in the *same* program depending on use of #ifdef #undef etc, thus
> making code navigation quite impossible: the meaning of each module now
> depends on how you got there and might even be different the second time
> round...


Notice that with my suggestions none of these problems apply, because all
external "command line" parameters have a single static value over the whole
program (two modules cannot depend on differing values of a single macro,
#undef is not allowed). Changing the bindings for these macros would
invalidate any cached information the editor has. But, the editor has to
support updating its caches anyway, to deal with switching libraries in/out,
etc.

I won't use an IDE effectively if it can't handle the libraries in FPTOOLS,
which liberally use the preprocessor. Either the IDE has to handle the
preprocessor or the libraries have to stop using them, or they have to meet
somewhere in the middle.


I think the acid test would be to reach a point where anyone can download
> the source for some large program such as GHC and just type ghc --make
> Main
> and expect the program to be built in one pass with no problems.


I agree with this sentiment as well. Most of the little data processing
programs I have written are built exactly like that already. How can we get
the existing libraries to build like that though?

- Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/haskell-cafe/attachments/20060821/0c1e14bd/attachment.htm