Alex Jacobson wrote:
Extensions that change syntax are effectively declared by the use of
that syntax. If you can parse the source, then you know which
extensions it uses.
I thought we'd already established that this isn't possible. Here are some
code fragments that parse differently depending on which extensions are
enabled:
f x y = x 3# y
f x = [d|d<-xs]
foreign x = x
f :: forall -> forall -> forall
You could argue that these syntax extensions are therefore badly designed,
but that's a separate discussion.
Cheers,
Simon
-Alex-
Duncan Coutts wrote:
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 structure.
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.
Duncan
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
