On Thu, Apr 05, 2007 at 07:07:34PM +0100, David House wrote:

On 05/04/07, John Meacham wrote:

...

A very big problem with the pragma as it relates to Distribution.Extension is that it is unextensable.

Yet another use case for Andres Löh and Ralf Hinze's open datatypes [1]. Shame they're still lacking an implementation.

[1]: http://www.informatik.uni-bonn.de/~loeh/OpenDatatypes.html

Well, The mistake is making them a data type at all, cabal doesn't do anything with them other than pass them to the appropriate compiler (perhaps after translating them to flags if the compiler doesn't support the LANGUAGE pragma). it should not have to enumerate a set of valid ones inside its code, just translation tables for the various compilers (or a note saying the compiler supports the LANGUAGE pragma, so the table isn't needed) likewise for the License field and getting rid of all built in preprocessors. cabal is just too inflexible (and much bigger than it needs to be) with so much stuff built in. ideally, the compilers would also not be hard coded into it, but that would be a bigger task but fixing up the rest shouldn't be hard. as a compiler writer, what I would love is if there were a document on the cabal site that said "to allow cabal to use your compiler, have it (or a wrapper) accept the following command line options and do X with them" likewise for a preprocessor or a language extension. none of these should require editing cabals code at all or require people to put something odd in their Setup.hs files to support the new compiler. perhaps what can be done for compiler support is to add a new 'common api' that newer compilers can use and a real --compiler option rather than the current --ghc --hugs hardcoded stuff. it should be just as easy as adding a specific hard-coded 'jhc' target and wouldn't feel so dirty. :) John -- John Meacham - ⑆repetae.net⑆john⑈