Hi all, Sven Panne wrote:
Furthermore, I don't think that the "C" in CPP is a real problem, at least in the traditional mode. 99% of the uses of a preprocessor for Haskell was simply for ironing out some platform/implementation differences, nothing very elaborate.
I guess we're straying away from the original topic. The question here is not how elaborate things one is trying to do with a CPP-like preprocessor. The question is if a Haskell source file gets passed through CPP at all, and if so, to what extent the preprocessor is able to cope with Haskell identifiers, string and character constants, comments, etc.
So we don't really need a Haskell-aware preprocessor, just something which doesn't stumble over common Haskell constructs and behaves consistently.
Of course one can argue that the problem isn't that bad. After all, people have managed to use CPP for very serious work for years. But clearly the situation is not ideal. Try using the perfectly legal Haskell operator /* in some code that gets fed through CPP, for example. (I, involuntary, did try! ;-) And for another example, why shouldn't one use Haskell's feature for string gaps? They are certainly useful from time to time to layout code neatly. The bottom line is that as long as code is syntactically legal Haskell, one should not have to worry if all constructs in the source file falls into the subset of "common" Haskell constructs, whatever that is. So, coming back to Cabal, that's why I think it at least should be easy to somehow specify selective preprocessing. Be it by some kind of file extension, which seems resonable to me, or by some form of option pragma in the text of the source file. I care about these things mainly because I have had problems with CPP and Haskell in practice, and we even went to quite great lengths in the Yale build system (mainly used for Yampa, but it was supposed to be of general use) to ameliorate the problem of having to rely on C-centric preprocessing for Haskell code by making selective preprocessing easy. (As an added bonus, there's also a small performance benefit of CPP-ing only what's necessary.) However, ultimately I still think the right solution is a preprocessor that does understand Haskell's lexical syntax. I agree that it could be like CPP in all other ways, and thus mainly suitable for doing "not very elaborate" things. In fact, it would probbaly be a good thing if it only was suitable for doing very simple things. Best regards, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn@cs.nott.ac.uk This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.