X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=ghc%2Fdocs%2Fusers_guide%2Fbugs.xml;fp=ghc%2Fdocs%2Fusers_guide%2Fbugs.xml;h=76ab87ddd70ed194d605774aeb6247b305a0fe72;hb=b9de29ac3fbf5192049a0bcaf1ab0c8bbbd57a83;hp=0000000000000000000000000000000000000000;hpb=69907617d58f6a97f7dc0b5e03b2fa0931ee686f;p=ghc-hetmet.git diff --git a/ghc/docs/users_guide/bugs.xml b/ghc/docs/users_guide/bugs.xml new file mode 100644 index 0000000..76ab87d --- /dev/null +++ b/ghc/docs/users_guide/bugs.xml @@ -0,0 +1,361 @@ + + + Known bugs and infelicities + + + Haskell 98 vs. Glasgow Haskell: language non-compliance + + + GHC vs the Haskell 98 language + Haskell 98 language vs GHC + + 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. + + The limitations here are listed in Haskell Report order + (roughly). + + + Divergence from Haskell 98 + + + + 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. + + + + 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 in expressions during + parsing. For example, according to the Haskell report, the + following expression is legal Haskell: + + let x = 42 in x == 42 == True + and parses as: + + (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 + + None known. + + + + Declarations and bindings + + None known. + + + + Module system and interface files + + None known. + + + + Numbers, basic types, and built-in classes + + + + Multiply-defined array elements—not checked: + + This code fragment should + elicit a fatal error, but it does not: + + +main = print (array (1,1) [(1,2), (1,3)]) +GHC's implemetation of array takes the value of an +array slot from the last (index,value) pair in the list, and does no +checking for duplicates. The reason for this is efficiency, pure and simple. + + + + + + + + + In <literal>Prelude</literal> support + + + + Arbitrary-sized tuples + + Tuples are currently limited to size 100. HOWEVER: + standard instances for tuples (Eq, + Ord, Bounded, + Ix Read, and + Show) are available + only up to 16-tuples. + + This limitation is easily subvertible, so please ask + if you get stuck on it. + + + + + Reading integers + + GHC's implementation of the + Read class for integral types accepts + hexadecimal and octal literals (the code in the Haskell + 98 report doesn't). So, for example, +read "0xf00" :: Int + works in GHC. + A possible reason for this is that readLitChar accepts hex and + octal escapes, so it seems inconsistent not to do so for integers too. + + + + + + + + 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. + + + + + The Char type + Charsize of + + + Following the ISO-10646 standard, + maxBound :: Char in GHC is + 0x10FFFF. + + + + + + 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. + + 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. + + + Negative literals, such as -3, are + specified by (a careful reading of) the Haskell Report as + meaning Prelude.negate (Prelude.fromInteger 3). + So -2147483648 means negate (fromInteger 2147483648). + Since fromInteger takes the lower 32 bits of the representation, + fromInteger (2147483648::Integer), computed at type Int is + -2147483648::Int. The negate operation then + overflows, but it is unchecked, so negate (-2147483648::Int) is just + -2147483648. In short, one can write minBound::Int as + a literal with the expected meaning (but that is not in general guaranteed. + + + The fromIntegral function also + preserves bit-patterns when converting between the sized + integral types (Int8, + Int16, Int32, + Int64 and the unsigned + Word variants), see the modules + Data.Int and Data.Word + in the library documentation. + + + + + 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. + + + + + + + + + + Known bugs or infelicities + + In addition to the divergences from the Haskell 98 standard + listed above, GHC has the following known bugs or + infelicities. + + + Bugs in GHC + + + + GHC can warn about non-exhaustive or overlapping + patterns (see ), and usually + does so correctly. But not always. It gets confused by + string patterns, and by guards, and can then emit bogus + warnings. The entire overlap-check code needs an overhaul + really. + + + + GHC does not allow you to have a data type with a context + that mentions type variables that are not data type parameters. + For example: + + data C a b => T a = MkT a + + so that MkT's type is + + MkT :: forall a b. C a b => a -> T a + + In principle, with a suitable class declaration with a functional dependency, + it's possible that this type is not ambiguous; but GHC nevertheless rejects + it. The type variables mentioned in the context of the data type declaration must + be among the type parameters of the data type. + + + + GHC's inliner can be persuaded into non-termination + using the standard way to encode recursion via a data type: + + data U = MkU (U -> Bool) + + russel :: U -> Bool + russel u@(MkU p) = not $ p u + + x :: Bool + x = russel (MkU russel) + + + We have never found another class of programs, other + than this contrived one, that makes GHC diverge, and fixing + the problem would impose an extra overhead on every + compilation. So the bug remains un-fixed. There is more + background in + Secrets of the GHC inliner. + + + + + + Bugs in GHCi (the interactive GHC) + + + GHCi does not respect the default + declaration in the module whose scope you are in. Instead, + for expressions typed at the command line, you always get the + default default-type behaviour; that is, + default(Int,Double). + + It would be better for GHCi to record what the default + settings in each module are, and use those of the 'current' + module (whatever that is). + + + + GHCi does not keep careful track of what instance + declarations are 'in scope' if they come from other packages. + Instead, all instance declarations that GHC has seen in other + packages are all in scope everywhere, whether or not the + module from that package is used by the command-line + expression. + + + + On Windows, there's a GNU ld/BFD bug + whereby it emits bogus PE object files that have more than + 0xffff relocations. When GHCi tries to load a package affected by this + bug, you get an error message of the form + +Loading package javavm ... linking ... WARNING: Overflown relocation field (# relocs found: 30765) + + The last time we looked, this bug still + wasn't fixed in the BFD codebase, and there wasn't any + noticeable interest in fixing it when we reported the bug + back in 2001 or so. + + The workaround is to split up the .o files that make up + your package into two or more .o's, along the lines of + how the "base" package does it. + + + + + + + +