Ross Paterson writes:

A couple of remarks about the current design:

Currently the output of preprocessing is left in the same directory as the source.

Yeah, I don't like this. I hope to fix it.

For Hugs, it would be more convenient to preprocess a source tree to make a new tree, especially if cpp turns Foo.hs into Foo.hs.

We originally had it move all the files into a temporary spot, then preprocss, then build. One problem with that, of course, is the threat of an IDE bringing up an error in one of the files that's been moved, the user fixing it, running the build again, and having the same error.

The restriction to extensions delimited with '.' rules out things like *_hsc_make.c (portable output of hsc2hs).

Can you make a small example of this for me to put in my test directory?

It might be preferable not to unlit .lhs files, as all implementations can handle them, and the originals are better for human readers (such as Hugs users curious about their libraries). There's no real need to unlit .ly files either, though some other preprocessors will need it. (And should unlit be treated as just another preprocessor?)

Yeah... should we get rid of the unlit preprocessor?

As I understand it, preprocessing with cpp is only needed for Hugs, as the compilers have -cpp flags, and will do it properly themselves. For Hugs, cpp will need a -D__HUGS__ option, plus extra options that are often system-dependent (and will also be needed by the compilers). This harks back to the need to separate system-dependent build parameters from the package description, and provide hooks to generate and use them.

I'll try to think more about this. peace, isaac