suggestion: add a .ehs file type

[Simon Marlow]

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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>