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