Hi Neil,

If you have two features battling each other, you probably need to remove one of them. CPP isn't going to be removed, which kind of forces the issue...

Well, for the record, I've used both CPP and string gaps extensively. And all I've done is to be careful to run CPP only where needed (and avoid string gaps there), which seems rather sensible to me anyway, string gaps or not. If various build-systems make selective CPP-ing hard, then I'd definitely argue that the build systems ought to be fixed (I can't believe that would be terribly hard: I've at least done it successfully using make. Not much fun, admittedly, but entirely feasible. Should be much simpler in the context of a more principled, Haskell-oriented build system.)

If you have two features battling each other, you probably need to remove one of them. CPP isn't going to be removed, which kind of forces the issue...

Well, first of all, I don't think CPP is a feature of Haskell. I do see your point from a pragmatic perspective, but I would argue that auxiliary tool issues (be it CPP, syntax highlighting, or what have you) should be of secondary concern when it comes to language design. As to CPP and Haskell in general, as a matter of principle, I think it's a bad idea to run a preprocessor intended for one very different language on programs of another. Cpphs makes much more sense. However, an advanced Haskell user who thinks CPP is necessary, should understand the implications and take appropriate precautions. So, I still don't find the rationale for removing string gaps very compelling, I'm afraid! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

Hi Neil,

...

Well, for the record, I've used both CPP and string gaps extensively. And all I've done is to be careful to run CPP only where needed (and avoid string gaps there), which seems rather sensible to me anyway, string gaps or not.

Having two "features" which can't be used together in the same file seems ridiculous.

Again, CPP is not part of Haskell as such, and I hope it won't become part either. So anyone using CPP with Haskel should know what they are doing. True, it so happens that CPP does get use a fair bit with Haskell for various reasons, and there is some dedicated tool support for CPP. So it would be good if the version of CPP used through a Haskell tool chain was Haskell aware.

It gets much worse if you decide "ghc --make -cpp" is the way you want to build your application, as we used to do for Yhc.

Wouldn't {-# LANGUAGE CPP #-} be a viable option in the, presumably rather few, files where CPP really is used? (That's also rather good documentation for the reader of the file, incidentally.) Again, running an entire project through CPP just because a few files needs CPP-ing, is something I at least would try to avoid.

I suggest that if string gaps don't get removed, then GHC should fix its -cpp flag.

Would be nice, but probably not an H' discussion topic, unless you're arguing that some kind of CPP facility is mandated by the H' standard? Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

Am Donnerstag, 3. April 2008 20:24 schrieb Simon Marlow:

Neil Mitchell wrote: […]

...

Having two "features" which can't be used together in the same file seems ridiculous. It gets much worse if you decide "ghc --make -cpp" is the way you want to build your application, as we used to do for Yhc. I suggest that if string gaps don't get removed, then GHC should fix its -cpp flag.

GHC is unlikely to "fix" its -cpp flag unfortunately, because the problem is with CPP, not GHC. The best we can do is document the problem, which we have done.

Couldn’t you “fix” the -cpp flag by letting GHC use cpphs instead of C’s cpp?

Cheers, Simon

Best wishes, Wolfgang

John Meacham:

On Tue, Apr 01, 2008 at 09:47:30PM +0100, Neil Mitchell wrote:

...

* string gaps cause problems with CPP, which doesn't like the backslash at the end of the line. (a minor consideration, since CPP is not part of the language, and in any case there is cpphs).

Between the two, I'd say CPP is the much uglier beast. (I tend to use m4 actually when I must use a preprocessor in general, it meshes with haskell better and is pretty ubiquitous). In any case, the simple solution of not using CPP in the same file as string gaps works quite well. It has never really been an issue before.

Repeat after me: CPP is evil! Plus I like strings gaps and have used them a lot. Manuel

I wonder if I should suggest removing all those strange ascii esacpe sequences next...

Well, in contrast to string gaps, I don't think I've ever used those! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.