Haskell 2010 draft report

[Simon Marlow]

On 01/05/2010 13:18, Ian Lynagh wrote:
> On Fri, Apr 30, 2010 at 05:05:17PM +0100, Simon Marlow wrote:
>> I've completed most of the edits to the Haskell 98 report for Haskell
>> 2010, modulo the changes to the libraries that we still have to resolve.
>>
>> I cleaned up various other things I discovered along the way, and tidied
>> up the typesetting.  I've also made a much nicer HTML rendering of the
>> report using TeX4ht, which means we can ditch the old 1500 lines of
>> hacked up Haskell code which used to do the HTML conversion before.
>>
>> You can see the draft report here, in PDF and online HTML respectively:
>>
>> http://www.haskell.org/~simonmar/haskell-2010-draft-report.pdf
>> http://www.haskell.org/~simonmar/haskell-2010-draft-report/haskell.html
>>
>> In the PDF you'll notice that the bits that changed in Haskell 2010
>> relative to Haskell 98 are purple (except for the FFI chapter).
>> Unfortunately I haven't yet managed to make this work in the HTML
>> version, but it ought to be possible.
>>
>> I'd appreciate a few more eyes over this, in particular look out for
>> messed up typesetting as there could still be a few bugs lurking.
>
> In the PDF:
>
> p37: "guard  -->   pat<- infixexp"
>       Is that really meant to be infixexp, not exp? GHC accepts:
>           foo
>            | True<- True :: Bool
>                = 'a'
>
> p37: Hmm, likewise "guard  -->   infixexp". GHC accepts
>           foo
>            | True :: Bool
>                = 'a'
>       but hugs doesn't (unexpected `::'). So I guess these are both
>       just GHC bugs, although I wonder why the report isn't more liberal.

See the bottom of 3.13:

"
A note about parsing. The expression
   case x of { (a,_) | let b = not a in b :: Bool -> a }

is tricky to parse correctly. It has a single unambiguous parse, namely
   case x of { (a,_) | (let b = not a in b :: Bool) -> a }

However, the phrase Bool -> a is syntactically valid as a type, and 
parsers with limited lookahead may incorrectly commit to this choice, 
and hence reject the program. Programmers are advised, therefore, to 
avoid guards that end with a type signature — indeed that is why a guard 
contains an infixexp not an exp.
"


In Haskell 98 we had

   gd -> | exp^0

where exp^0 is now called infixexp, so I kept things as they were.

Arguably using infixexp here is only a partial fix for the parsing 
problem described above, and so it might be better not to try to fix the 
problem at all.  Either way though, GHC will be wrong.

> p42: The negative literal alternative in pat is redundant

well spotted, thanks.

> p47: I'm not sure I see the reason for this change. It seems to just
>       make it more complicated. If the change is made, should say y is a
>       new variable.
>       I don't know if the colouring is important, but there's a black "y"
>       that should be purple, and two purple "_ ->" that should be black,

Agreed, I've reverted that.

> p47: Case (h) is alone in ending in a full stop
>
> p48: Case s, again I don't see the point of the y binding

Fixed.  Thanks!

Simon