ghc_extra_opts in package

[Alastair David Reid]

[Discussion moves to libraries list]

Simon Marlow:

> Arguably there ought to be some other indication in the source code
> of what non-standard features a module requires - the closest we
> come to this at the moment is that GHC allows you to say

> 	{-# OPTIONS -fglasgow-exts #-}

> to enable GHC extensions in the source.

If we went in this direction, we'd need to make it compiler independent
and finer grained.  

I also feel uncomfortable putting it in the source file but I can't
quite put my finger on why.

> Another issue is that it turns out to be hard to enable certain
> extensions without enabling others, because it requires you to pass
> around more state in the compiler, and in particular in the parser
> (the number of different languages being parsed increases), which is
> why we lump all the extensions together in GHC.  However, I agree
> the situation isn't ideal.

So here's a concrete suggestion:

1) We standardise the definition of various extensions (mptc, unboxed types,
   etc.) so that if two compilers both claim to support feature X, then
   they accept the same code.  (We're pretty close to this already.)

   Note that standardising the definition of mptc (for example) isn't
   the same as requiring all Haskell compilers to support it.

   Here's a list of proposed standards (suggestions for extra features
   welcome):

     MPTC
     FunctionalDependencies
     PatternGuards
     UnboxedTypes
     TREX
     PreemptiveConcurrency
     CooperativeConcurrency
     ImplicitParameters
     ExceptionHandling
     FFI

2) We extend the package definition with a list of features used in the
   package.

   Package {
     name = "net",
     extensions = [ "FFI", "ExceptionHandling", ... ],
     ...
   }

3) Package managers translate these standard feature names into a 
   set of compiler-specific flags to pass to the compiler.

   It would be considered ok for a compiler to enable other extensions
   at the same time or to have some extensions permanently enabled.

   (It would also be good if at least one of the compilers supporting
   each feature generated a warning if you used a feature not
   mentioned in the package spec.  This check might occur while
   checking static semantics, typechecking, etc. (where it is easy to
   be selective) instead of being enforced in the parser.

-- 
Alastair Reid        reid@cs.utah.edu        http://www.cs.utah.edu/~reid/