On 20 October 2004 17:03, Peter Simons wrote:
Sven Panne writes:
If you mean "everyone happy with a LGPL", then I would agree. But GHC and Hugs use a BSD-style license, so cpphs is not an option for them.
Why not?
I wouldn't go so far as to say "not an option", but we definitely prefer as much of the system to be BSD-licensed as possible. It makes life much easier for our commercial users. I could talk at length on the subject, but life's too short :-p Cheers, Simon
Simon Marlow wrote:
On 20 October 2004 17:03, Peter Simons wrote:
Sven Panne writes:
If you mean "everyone happy with a LGPL", then I would agree. But GHC and Hugs use a BSD-style license, so cpphs is not an option for them. Why not? I wouldn't go so far as to say "not an option", but we definitely prefer as much of the system to be BSD-licensed as possible. It makes life much easier for our commercial users. I could talk at length on the subject, but life's too short :-p
I can only second that. I'm currently working for a very large company, and licensing issues are something very serious for such institutions. If there are any doubts about licenses, a technology will simply be ignored just for that reason. I know enough managers who will run away screaming if they hear "(L)GPL", so staying with the *much* more industry-friendly BSD license will be a good thing for GHC IMHO. I don't want to start a useless flame war about licenses, I just wanted to make my motivation clear: Like it or not, the (L)GPL is an obstacle for the introduction of new technologies in the industry, at least this is how I experienced this issue. This has nothing to do with my personal opinion, though... 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. So we don't really need a Haskell-aware preprocessor, just something which doesn't stumble over common Haskell constructs and behaves consistently. Cheers, S.
Sven Panne
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.
Speaking for the remaining 1%, I use cpp to get better error reporting for Prelude functions. I.e. I define head, fromJust etc. as macros, so that if the pattern match fails, I can get the exact place in the source, instead of an anonymous error message. 'C' becomes a problem in some cases, notably infix operators (which anyway are problematic, since I cannot surround an arbitrary expression with backticks and get infix behavior) and single quotes. But if there is a better way to do this, I'm all ears. -kzm PS: I put my darcs repo at http://www.ii.uib.no/~ketil/interlude It's really trivial, but feel free to use if and submit improvements. PPS: Talking about darcs, they (that is, David Roundy) also use this trick. -- If I haven't seen further, it is by standing in the footprints of giants
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.
participants (4)
-
Henrik Nilsson -
Ketil Malde -
Simon Marlow -
Sven Panne