suggestion: add a .ehs file type

[Alex Jacobson]

My original point (refined) was that I'd like a file extension (.ehs) 
that defaults to including all extensions that don't change the meaning 
of a .hs program but that may cause a small subset of them not to 
compile (e.g. ones that use forall as a type variable, foreign as a 
function, or 'd' as the result value of a list comprehension)

This does not seem like a major change, does not break any existing 
code, and has the advantage of making it really obvious when people are 
going beyond haskell98.

-Alex-

Simon Marlow wrote:
> I see, all you're saying is you'd like the default to be different.
> 
> (That's not the same as saying "Extensions that change syntax are 
> effectively declared by the use of that syntax", which is what you said 
> earlier, BTW.)
> 
> Well, we could change the default.  I don't think it's a great idea 
> personally - I think we should default to compiling whatever is the most 
> recent standard, i.e. Haskell 98.  But you're arguing that the 
> proportion of Haskell 98 code that would fail to compile is relatively 
> small; that might well be true.  This isn't a decision we could take 
> lightly, though.
> 
> Furthermore, it's only something we could change in 6.10, by which time 
> it is likely that we'll have a clearer idea of what Haskell' is, so 
> there might well be a -fhaskell-prime flag (or it might even be the 
> default).
> 
> Cheers,
>     Simon
> 
> Alex Jacobson wrote:
>>
>> 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
>>>>>>
>>>>
>>>>
>>
>>