- ghc-tickets - Haskell.org

[GHC] #9674: Foldable doesn't have any laws
by GHC 13 Feb '15

13 Feb '15

#9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The documentation for `Foldable` doesn't list any laws. I don't know exactly what its laws may be, but there are, at least, several implicit in the default method definitions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10084: Data.List should have a takeLastN function
by GHC 12 Feb '15

12 Feb '15

#10084: Data.List should have a takeLastN function -------------------------------------+------------------------------------- Reporter: leonbaum2 | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- A natural compliment to the `take` function that instead takes `n` elements from the end of the list rather than from the start would be very useful. I'm surprised it's not defined in base because it seems to be a common operation that is not trivial to define in an efficient way. See http://www.joachim- breitner.de/blog/600-On_taking_the_last_n_elements_of_a_list -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10084> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10082: Church Booleans - xor
by GHC 12 Feb '15

12 Feb '15

#10082: Church Booleans - xor -------------------------------------+------------------------------------- Reporter: honza889 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I use following implementation of Church Booleans, all is ok: {{{#!hs lTrue = \x y -> x lFalse = \x y -> y lNot = \t -> t lFalse lTrue lXor = \u v -> u (lNot v) (lNot lNot v) lXor' = \u v -> u (v lFalse lTrue) (v lTrue lFalse) }}} But this simplified versions of lXor fails, if first parameter is lFalse: {{{#!hs lXor'' = \u v -> u (lNot v) (v) -- not work, bug in ghc? lXor''' = \u v -> u (lNot v) v -- not work, bug in ghc? }}} {{{#!hs GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help Prelude> :l lambda.hs [1 of 1] Compiling Main ( lambda.hs, interpreted ) Ok, modules loaded: Main. *Main> (lXor'' lFalse lFalse) 1 0 <interactive>:3:1: Non type-variable argument in the constraint: Num (t5 -> t4 -> t5) (Use FlexibleContexts to permit this) When checking that ‘it’ has the inferred type it :: forall t4 t5. Num (t5 -> t4 -> t5) => t5 -> t4 -> t5 <interactive>:3:24: Could not deduce (Num (t20 -> t30 -> t30)) arising from the literal ‘1’ from the context (Num (t5 -> t4 -> t5)) bound by the inferred type of it :: Num (t5 -> t4 -> t5) => t5 -> t4 -> t5 at <interactive>:3:1-26 The type variables ‘t20’, ‘t30’ are ambiguous In the third argument of ‘lXor''’, namely ‘1’ In the expression: (lXor'' lFalse lFalse) 1 0 In an equation for ‘it’: it = (lXor'' lFalse lFalse) 1 0 }}} Because both lXor implementations in first example works ok, I believe this is bug in ghc. But similar problem occure in older versions of ghc: {{{#!hs GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :l lambda.hs [1 of 1] Compiling Main ( lambda.hs, interpreted ) Ok, modules loaded: Main. *Main> (lXor'' lFalse lFalse) 1 0 <interactive>:3:24: No instance for (Num (t20 -> t30 -> t30)) arising from the literal `1' Possible fix: add an instance declaration for (Num (t20 -> t30 -> t30)) In the third argument of lXor'', namely `1' In the expression: (lXor'' lFalse lFalse) 1 0 In an equation for `it': it = (lXor'' lFalse lFalse) 1 0 <interactive>:3:26: No instance for (Num (t50 -> t40 -> t50)) arising from the literal `0' Possible fix: add an instance declaration for (Num (t50 -> t40 -> t50)) In the fourth argument of lXor'', namely `0' In the expression: (lXor'' lFalse lFalse) 1 0 In an equation for `it': it = (lXor'' lFalse lFalse) 1 0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 12 Feb '15

12 Feb '15

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8550 | -------------------------------------+------------------------------------- Comment (by goldfire): Just took a quick look at this, as I was in the area. This will take some plumbing to implement right, sadly. The problem is that the type family reduction happens in the bowels of the flattening algorithm. To do this right, we need to update the `CtLoc` of the relevant constraint, but there's no good way to do that from the middle of the flattener. Two ways forward: 1. Install the plumbing. I vote that this should be a new `FlatM` monad (built on `TcS`) that allows updating of the `CtLoc` currently stored in the `FlattenEnv`. `FlatM` would gather up the `FlattenEnv` stuff, the `runFlatten` stuff, and this new type-family-depth-counting stuff. Seems like enough stuff to make it a new structure. 2. Have a local counter just for the new, eager type family reduction. We have access to `DynFlags`, of course, so we can check if the number of eager reductions is more than requested. We can even add the number of eager reductions to the number of reductions done previously. What we can't do is record the number of eager reductions. So, if the stack depth were 200, then this plan (2) would allow, say, 190 eager reductions at one go, then some other solving, and then another 190 eager reductions, and then some solving, and so on. The depth is still bounded, but it makes it nigh impossible for a programmer to relate their choice of `-ftype- function-depth` to GHC's behavior, as it all depends on where the reduction takes place. Thoughts? Still no promises on getting to this for real before March, I'm afraid, especially for option 1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 11 Feb '15

11 Feb '15

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8550 | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: simonpj => goldfire * related: => #8550 * milestone: 7.12.1 => 7.10.1 Comment: I just noticed that I had been asked to do this, and I think it would be nice in 7.10. However, the fix would potentially be user-facing: A type-family-heavy program that compiles on 7.10.1RC2 might need to set `-ftype-function- depth` after the fix. Is that acceptable at this point? Also, time is very precious for me before Feb. 27. I can get right on this Mar. 2. (See also #8550, which is probably a dup of this bug.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7765: Odd error message for `runghc` with missing `main` function.
by GHC 11 Feb '15

11 Feb '15

#7765: Odd error message for `runghc` with missing `main` function. -------------------------------------+------------------------------------- Reporter: isaacdupree | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #414 | module/T7765 | Blocking: | Differential Revisions: Phab:D649 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => module/T7765 * differential: => Phab:D649 * related: => #414 Comment: With Phab:D649, `Main` without `main` is always an error, regardless of the mode of operation: `ghc`, `ghci` or `runhaskell` (=`ghc -e main`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7765#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #414: GHC does not eforce that Main exports main
by GHC 11 Feb '15

11 Feb '15

#414: GHC does not eforce that Main exports main -------------------------------------+------------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: lowest | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | module/T414 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * testcase: mod174 => module/T414 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/414#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1103: Japanese Unicode
by GHC 10 Feb '15

10 Feb '15

#1103: Japanese Unicode -------------------------------------+------------------------------------- Reporter: humasect | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 Component: Compiler | branch (Parser) | Version: 6.6 Resolution: fixed | Keywords: japanese Operating System: Unknown/Multiple | unicode lexical -fglasgow-exts Type of failure: None/Unknown | report-impact Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * keywords: japanese unicode lexical -fglasgow-exts => japanese unicode lexical -fglasgow-exts report-impact * failure: => None/Unknown -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1103#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9213: CPP warnings on ghcautoconf.h
by GHC 10 Feb '15

10 Feb '15

#9213: CPP warnings on ghcautoconf.h ------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The cpphs program yields the following warning: {{{ Warning: trailing characters after #if directive in file ... /ghcautoconf.h at line 383 col 1: AC_APPLE_UNIVERSAL_BUILD }}} I guess it is necessary to replace `#if defined` by `#ifdef` in the line {{{ #if defined AC_APPLE_UNIVERSAL_BUILD }}} from the mk/config.h.in file. Note the next line `# if defined __BIG_ENDIAN__` has the same issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9213> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #7103: Compiler panic, when loading wxc in GHCi
by GHC 09 Feb '15

09 Feb '15

#7103: Compiler panic, when loading wxc in GHCi -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: 3658 | Test Case: Related Tickets: #9907, #10051 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by darthdeus): I ran into the same thing while trying to get the `mysql` package working, where after many changes I was able to get the package to successfully compile on its own, but while linking with a larger application this error essentially killed the deployment, since there doesn't seem to be a way to work around it. Removing the idata$4 section with `--no-idata4` yielded the same error with idata$5, so we tried removing that with `--no-idata5`, but then ran into the same issue with idata$7. ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc.exe: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of __imp_getaddrinfo ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of __imp_freeaddrinfo ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: Unknown PEi386 section name `.idata$7' (while processing: C:\Haskell\ert\.cabal-sandbox\x86_64-windows- 7\libmysql.a) cabal: Error: some packages failed to install: We also tried modifying dlltool to remove the idata$7 section as well (source https://sourceware.org/git/?p=binutils.git;a=blob;f=binutils/dlltool.c) but without any success. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7103#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0