suggestion: add a .ehs file type
duncan.coutts at worc.ox.ac.uk
Fri Nov 23 12:10:27 EST 2007
On Fri, 2007-11-23 at 16:26 +0100, Wolfgang Jeltsch wrote:
> Am Freitag, 23. November 2007 03:37 schrieben Sie:
> > On Fri, 2007-11-23 at 01:50 +0100, Wolfgang Jeltsch wrote:
> > > Dont’t just think in terms of single modules. If I have a Cabal package,
> > > I can declare used extensions in the Cabal file. A user can decide not
> > > to start building at all if he/she sees that the package uses an
> > > extension unsupported by the compiler.
> > Indeed. In theory Cabal checks all the extensions declared to be used by
> > the package are supported by the selected compiler. In practise I'm not
> > sure how well it does this or what kind of error message we get.
> The problem is, of course, that you are not forced to specify all used
> extensions in the Cabal file since you can still use language pragmas.
> Sometimes it is even desirable to use LANGUAGE pragmas instead of information
> in the Cabal file. For example, even if some modules use undecidable
> instances, I might not want all modules of the package to be compiled
> with -XUndecidableInstances since this could hide problems with my class
Our tentative plan there is to separate the extensions field into those
used in some module, and those applied by cabal to every module. So that
would allow you to specify a feature in one file but not all, while
still declaring to the outside world that the package uses the feature.
As for enforcing that, that may come almost for free when we get
dependency chasing as we'll be looking for imports anyway. It shouldn't
be much harder to look for language pragmas too.
More information about the cabal-devel