Re: ghc_extra_opts in package
[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/
On 27 Jun 2001, Alastair David Reid wrote:
[..]
2) We extend the package definition with a list of features used in the package.
Package { name = "net", extensions = [ "FFI", "ExceptionHandling", ... ], ... }
This seems to be a very clear, high level, specification. I'd vote for it, or something of this sort. It clearly specifies up front what is really needed to use a particular module and it does it in a human-readable format. Ideally, I'd like to see it as a part of future Haskell Report. Frankly, all those compiler switches - no matter how powerful and familiar they are to those using, GHC say, compiler - make me feel quite uncomfortable; they resemble a jungle of switches specific to GCC or to other specific C compilers. With all due respect, Haskell supposes to be both a high level language and a system of high level libraries - not something augmented by a set of low level rules about switches and macros. Jan
Alastair David Reid
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", ... ], ... }
Sounds like an excellent idea to me. Cheers, Manuel
participants (3)
-
Alastair David Reid -
Jan Skibinski -
Manuel M. T. Chakravarty