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.