suggestion: add a .ehs file type
simonmarhaskell at gmail.com
Mon Nov 26 04:26:13 EST 2007
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
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.
> 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
>>>>> I can declare used extensions in the Cabal file. A user can decide
>>>>> 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.
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the cabal-devel