[Haskell] -compiler-options vs {#-LANGUAGE Flags-#}

[John Meacham]

On Thu, Apr 05, 2007 at 07:07:34PM +0100, David House wrote:
> On 05/04/07, John Meacham <john at repetae.net> 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⑈