suggestion: add a .ehs file type

[Alex Jacobson]

Simon, I think we've been trying to be too clever...

The simple question is: for a given extension, what is the risk of 
leaving it turned on by default?

Clearly we don't want extensions turned on that causes code to compile 
but with a different meaning.  We may not want extensions turned on that 
cause most reasonable code not to compile.

But I would say neither risk is significant in the case of most 
extensions.  To use your examples:

* FFI doesn't not cause h98 code to compile to a different meaning.  The 
worst case is that code that uses 'foreign' as a function name doesn't 
compile.  That seems okay in that more code probably uses FFI than uses 
foreign as a function name and the user can apply a language pragma to 
turn it off if really desired.

* Existential types won't cause h98 code to compile with a different 
meaning.  The worst case is that code that uses 'forall' as a type 
variable won't compile.  That seems ok....

* TemplateHaskell also not compatible with h98.  The worst case is the 
loss "[d|" in list comprehensions.

* MagicHash: Does not appear in the ToC or the Index of the user's guide 
so should probably be turned off.  I have no idea what it does.

Note, in all cases where the extension is turned on by default, there 
should be a language pragma to turn it off.


-Alex-

Simon Marlow wrote:
> Alex Jacobson wrote:
>>
>> 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.
> 
> So for the first example I gave,
> 
> f x y = x 3# y
> 
> the "MagicHash" extension is one that you'd require to be explicitly 
> declared, because the expression parses both with and without the 
> extension.
> 
> Now, Let's take the Template Haskell example:
> 
> f x = [d|d<-xs]
> 
> So this is valid Haskell 98, but invalid H98+TH.  You would therefore 
> like this example to parse unambiguously as H98, correct?  But in order 
> to do that, our parser would need arbitrary lookahead: it can't tell 
> whether the expression is legal H98+TH until it gets to the '<-' in this 
> case. Certainly it's possible to implement this using a backtracking 
> parser, but Haskell is supposed to be parsable with a shift-reduce 
> parser such as the one GHC uses.  Or we could try parsing the whole 
> module with various combinations of extensions turned on or off, but I'm 
> sure you can see the problems with that.
> 
> So basically the problem is that you need a parser that parses a strict 
> superset of Haskell98 - and that's hard to achieve.
> 
> Cheers,
>     Simon
> 
>> 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
>>>>
>>
>>