3) shouldn't there be a way of telling ghc --make about ways to generate the .hs/.lhs files it is looking for (aka suffix rules)?
The standard examples are happy, cpp, drift, ..
If you are willing to switch from ghc --make to hmake, you get various common suffix rules for free. ..
It is also relatively straightforward to add more pre-processing rules of this nature to the hmake sources. For example, do you have a suggestion for a DrIFT suffix?
.hs.d? Strafunski uses .ds .. hmm, perhaps I'll have another look at hmake. It's just nice to get going without extra tools (and without autoconfigured non-portable self-remaking recursive humbug..; no, I'm not thinking of hmake here, but some people simply get carried away when they encounter gnu-make&family;-). In the interests of portability, your ads for hmake are of course justified. The following may not apply to hmake, but while we are off the topic: the main problem I have with Makefiles of any sort is that they store a lot of information about my programs outside of the language tools. For instance, Haskell doesn't specify a common notion of a Haskell project, so this is currently either hidden in Makefiles or in all kind of tool-specific ad-hoc constructions for IDE-like things and similar tools. It would be nice if everything that's needed to understand a set of Haskell source files would be accessible from the sources (perhaps with the addition of some Haskell project specifications in a format pinned down in the language standard). That this isn't the case indicates that there are things missing from Haskell that are needed in practice (the common use of the _C_ preprocessor to selectively enable platform- or implementation-specific code is another sore point), and while there have been language-external ways around that, the differences that evolved from those ways are now in the way of further developments, such as IDEs (unless you're happy to be locked into one of them?). Cheers, Claus