[[project @ 2001-08-23 10:33:36 by simonmar] simonmar**20010823103336 Add a new section, documenting "GHC's take on behaviour that is left undefined or implementation specific in Haskell 98", and in it document the size of Int, the behaviour of fromIntegral, and the behaviour of floating-point exceptions. ] { hunk ./ghc/docs/users_guide/vs_haskell.sgml 1 - -Haskell 98 vs. Glasgow Haskell: language non-compliance - + + Haskell 98 vs. Glasgow Haskell: language non-compliance + hunk ./ghc/docs/users_guide/vs_haskell.sgml 5 - -GHC vs the Haskell 98 language -Haskell 98 language vs GHC - + GHC vs the Haskell 98 language + Haskell 98 language vs GHC hunk ./ghc/docs/users_guide/vs_haskell.sgml 8 - -This section lists Glasgow Haskell infelicities in its implementation -of Haskell 98. See also the “when things go wrong” section -() -for information about crashes, space leaks, and other undesirable -phenomena. - + This section lists Glasgow Haskell infelicities in its + implementation of Haskell 98. See also the “when things + go wrong” section () for information + about crashes, space leaks, and other undesirable phenomena. hunk ./ghc/docs/users_guide/vs_haskell.sgml 13 - -The limitations here are listed in Haskell-Report order (roughly). - + The limitations here are listed in Haskell-Report order + (roughly). hunk ./ghc/docs/users_guide/vs_haskell.sgml 16 - - Lexical syntax + + Divergence from Haskell 98 hunk ./ghc/docs/users_guide/vs_haskell.sgml 19 - - - The Haskell report specifies that programs may be - written using Unicode. GHC only accepts the ISO-8859-1 - character set at the moment. - + + + Lexical syntax + + + + The Haskell report specifies that programs may be + written using Unicode. GHC only accepts the ISO-8859-1 + character set at the moment. + hunk ./ghc/docs/users_guide/vs_haskell.sgml 30 - - Certain lexical rules regarding qualified identifiers - are slightly different in GHC compared to the Haskell report. - When you have - module.reservedop, - such as M.\, GHC will interpret it as a - single qualified operator rather than the two lexemes - M and .\. - - - - - - Context-free syntax - - - - GHC doesn't do fixity resolution on the left hand side - of a binding before deciding which symbol is the function - symbol. For example, the following fails, because GHC makes - the assumption that the function symbol is - |-: + + Certain lexical rules regarding qualified identifiers + are slightly different in GHC compared to the Haskell + report. When you have + module.reservedop, + such as M.\, GHC will interpret it as a + single qualified operator rather than the two lexemes + M and .\. + + + + + + Context-free syntax + + + + GHC doesn't do fixity resolution on the left hand side + of a binding before deciding which symbol is the function + symbol. For example, the following fails, because GHC makes + the assumption that the function symbol is + |-: hunk ./ghc/docs/users_guide/vs_haskell.sgml 58 -0 |- x:=y = 1 |- x:=y -- XXX fails here - - +0 |- x:=y = 1 |- x:=y -- XXX fails here + hunk ./ghc/docs/users_guide/vs_haskell.sgml 61 - - GHC doesn't do fixity resolution in expressions during - parsing. For example, according to the Haskell report, the - following expression is legal Haskell: + + GHC doesn't do fixity resolution in expressions during + parsing. For example, according to the Haskell report, the + following expression is legal Haskell: hunk ./ghc/docs/users_guide/vs_haskell.sgml 66 - let x = 42 in x == 42 == True - + let x = 42 in x == 42 == True hunk ./ghc/docs/users_guide/vs_haskell.sgml 69 - (let x = 42 in x == 42) == True - - because according to the report, the let - expression extends as far to the right as - possible. Since it can't extend past the second - equals sign without causing a parse error - (== is non-fix), the - let-expression must terminate there. GHC - simply gobbles up the whole expression, parsing like this: - - (let x = 42 in x == 42 == True) - - The Haskell report is arguably wrong here, but nevertheless - it's a difference between GHC & Haskell 98. - - - - - -Expressions and patterns - - - - - - -Very long String constants: - - -May not go through. If you add a “string gap” every -few thousand characters, then the strings can be as long -as you like. - + (let x = 42 in x == 42) == True hunk ./ghc/docs/users_guide/vs_haskell.sgml 71 - -Bear in mind that string gaps and the -cpp option -option don't mix very well (see ). - - - - -Single quotes in module names: - - -It might work, but it's just begging for trouble. - - - - - + because according to the report, the let + expression extends as far to the right as + possible. Since it can't extend past the second + equals sign without causing a parse error + (== is non-fix), the + let-expression must terminate there. GHC + simply gobbles up the whole expression, parsing like this: + + (let x = 42 in x == 42 == True) hunk ./ghc/docs/users_guide/vs_haskell.sgml 81 - + The Haskell report is arguably wrong here, but nevertheless + it's a difference between GHC & Haskell 98. + + + hunk ./ghc/docs/users_guide/vs_haskell.sgml 87 - -Declarations and bindings - + + Expressions and patterns hunk ./ghc/docs/users_guide/vs_haskell.sgml 90 - -None known. - + + + Very long String constants: + + May not go through. If you add a “string + gap” every few thousand characters, then the strings + can be as long as you like. hunk ./ghc/docs/users_guide/vs_haskell.sgml 98 - + Bear in mind that string gaps and the + + option don't mix very well (see + ). + + + hunk ./ghc/docs/users_guide/vs_haskell.sgml 106 - -Module system and interface files - + hunk ./ghc/docs/users_guide/vs_haskell.sgml 108 - - + + Declarations and bindings hunk ./ghc/docs/users_guide/vs_haskell.sgml 111 - - Namespace pollution - - -Several modules internal to GHC are visible in the standard namespace. -All of these modules begin with Prel, so the rule -is: don't use any modules beginning with Prel in -your program, or you will be comprehensively screwed. - - - - - + None known. hunk ./ghc/docs/users_guide/vs_haskell.sgml 113 - + hunk ./ghc/docs/users_guide/vs_haskell.sgml 115 - -Numbers, basic types, and built-in classes - + + Module system and interface files hunk ./ghc/docs/users_guide/vs_haskell.sgml 118 - - + hunk ./ghc/docs/users_guide/vs_haskell.sgml 120 - -Unchecked arithmetic: - - -Arguably not an infelicity, but… Bear in -mind that operations on Int, -Float, and Double numbers are -unchecked for overflow, underflow, and other sad -occurrences. (note, however that some architectures trap -floating-point overflow and loss-of-precision and report a -floating-point exception, probably terminating the -program)floating-point -exceptions. - + + Namespace pollution + + Several modules internal to GHC are visible in the + standard namespace. All of these modules begin with + Prel, so the rule is: don't use any + modules beginning with Prel in your + program, or you will be comprehensively screwed. + + + hunk ./ghc/docs/users_guide/vs_haskell.sgml 132 - -Use Integer, Rational, etc., -numeric types if this stuff keeps you awake at night. - - - - -Multiply-defined array elements—not checked: - - -This code fragment should elicit a fatal error, but it does not: + hunk ./ghc/docs/users_guide/vs_haskell.sgml 134 - -main = print (array (1,1) [(1,2), (1,3)]) - + + Numbers, basic types, and built-in classes hunk ./ghc/docs/users_guide/vs_haskell.sgml 137 - - - - - + + + Multiply-defined array elements—not checked: + + This code fragment should + elicit a fatal error, but it does not: hunk ./ghc/docs/users_guide/vs_haskell.sgml 144 - + +main = print (array (1,1) [(1,2), (1,3)]) hunk ./ghc/docs/users_guide/vs_haskell.sgml 147 - -In Prelude support - + + + + + + hunk ./ghc/docs/users_guide/vs_haskell.sgml 154 - - + + In Prelude support hunk ./ghc/docs/users_guide/vs_haskell.sgml 157 + hunk ./ghc/docs/users_guide/vs_haskell.sgml 171 - -Arbitrary-sized tuples: - - -Tuples are currently limited to size 61. HOWEVER: standard instances -for tuples (Eq, Ord, -Bounded, Ix -Read, and Show) are available -only up to 5-tuples. - + + Arbitrary-sized tuples: + + Tuples are currently limited to size 61. HOWEVER: + standard instances for tuples (Eq, + Ord, Bounded, + Ix Read, and + Show) are available + only up to 5-tuples. hunk ./ghc/docs/users_guide/vs_haskell.sgml 181 - -These limitations are easily subvertible, so please ask if you get -stuck on them. - - - - - + This limitation is easily subvertible, so please ask + if you get stuck on it. + + + + + + + + GHC's interpretation of undefined behaviour in + Haskell 98 + + This section documents GHC's take on various issues that are + left undefined or implementation specific in Haskell 98. + + + + Sized integral types + Intsize of + + + + In GHC the Int type follows the + size of an address on the host architecture; in other words + it holds 32 bits on a 32-bit machine, and 64-bits on a + 64-bit machine. hunk ./ghc/docs/users_guide/vs_haskell.sgml 208 - + Arithmetic on Int is unchecked for + overflowoverflowInt + , so all operations on Int happen + modulo + 2n + where n is the size in bits of + the Int type. + + The fromIntegerfromInteger + function (and hence + also fromIntegralfromIntegral + ) is a special case when + converting to Int. The value of + fromIntegral x :: Int is given by taking + the lower n bits of (abs + x), multiplied by the sign of x + (in 2's complement n-bit + arithmetic). This behaviour was chosen so that for example + writing 0xffffffff :: Int preserves the + bit-pattern in the resulting Int. + + + + + Unchecked float arithmetic + + Operations on Float and + Double numbers are + unchecked for overflow, underflow, and + other sad occurrences. (note, however that some + architectures trap floating-point overflow and + loss-of-precision and report a floating-point exception, + probably terminating the + program)floating-point + exceptions. + + + + + hunk ./ghc/docs/users_guide/vs_haskell.sgml 249 - + }