suggestion: add a .ehs file type

[Alex Jacobson]

Simon, from what I can tell, with GHC 6.8.1, use of foreign as a 
function name or forall as a type variable or leaving out a space in a 
list-comprehension doesn't "parse differently" when the relevant 
extensions are enabled, it causes a parse error.

Extensions allow the same code to parse but with different meanings need 
to be declared explicitly.  But, extensions that are obvious from syntax 
should be allowed to be declared simply from the use of that syntax.

I am not taking a position here on the merits of any extensions.

-Alex-


Simon Marlow wrote:
> 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
>>