January 2013 - ghc-tickets

Re: [GHC] #2222: Template Haskell: reify returns incorrect types when ommiting type signatures
by GHC 27 Jan '13

27 Jan '13

#2222: Template Haskell: reify returns incorrect types when ommiting type signatures ---------------------------------+------------------------------------------ Reporter: fons | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.8.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by morabbin): * failure: => None/Unknown Comment: TH has moved on a little, and now all of the decl splices act as expected by OP: {{{ Orac:~/work/ghc $ ghci -fth ReifyPlusTypeInferenceBugs.hs GHCi, version 7.6.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling ReifyPlusTypeInferenceBugs ( ReifyPlusTypeInferenceBugs.hs, interpreted ) Loading package pretty-1.1.1.0 ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package template-haskell ... linking ... done. inside d: t_0 inside b: a_0 type of c: GHC.Types.Bool inside f: GHC.Types.Bool type of e: GHC.Types.Bool Ok, modules loaded: ReifyPlusTypeInferenceBugs. }}} The output for `d` is precisely as OP reports, and output for `e` is the same modulo type variable change (from `t0` to `a0`). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2222#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2244: load in GHCi doesn't work with UTF-8 filenames
by GHC 27 Jan '13

27 Jan '13

#2244: load in GHCi doesn't work with UTF-8 filenames ---------------------------------+------------------------------------------ Reporter: malebria | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 6.8.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by morabbin): * failure: => None/Unknown Comment: Works for me, GHCi 7.6.1 on Mac, on command line and from within GHCi: {{{ Orac:~/work/ghc $ ls Bl* Blörgle.hs Orac:~/work/ghc $ ghci Blörgle.hs GHCi, version 7.6.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( Blörgle.hs, interpreted ) ... Orac:~/work/ghc $ ghci GHCi, version 7.6.1: 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 Blörgle.hs [1 of 1] Compiling Main ( Blörgle.hs, interpreted ) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2244#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2149: literate haskell support for hasktags - patch below
by GHC 27 Jan '13

27 Jan '13

#2149: literate haskell support for hasktags - patch below -------------------------------+-------------------------------------------- Reporter: MarcWeber | Owner: Type: feature request | Status: closed Priority: normal | Milestone: _|_ Component: None | Version: 6.8.2 Resolution: invalid | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: We no longer have `utils/hasktags` anyway; closing. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2149#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7613: readSigned consumes too much input
by GHC 27 Jan '13

27 Jan '13

#7613: readSigned consumes too much input ----------------------------------------+----------------------------------- Reporter: liyang | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- {{{ > reads "0.1" :: [(Int, String)] [] }}} I would have expected {{{[(0, ".1")]}}}. The Report specifies that {{{reads}}} for {{{Int}}} ought to essentially be {{{readSigned readDec}}}, and indeed {{{readDec}}} gives the expected result: {{{ > readDec "0.1" [(0,".1")] }}} I think the bug is due to the use of {{{lex}}} in {{{readSigned}}}, which consumes the entire "0.1" string, such that readDec no longer gives a clean parse. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7613> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1872: Extensible Records
by GHC 27 Jan '13

27 Jan '13

#1872: Extensible Records -------------------------------+-------------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.11 Resolution: wontfix | Keywords: Extensible Records Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: It looks like this needs more discussion on the lists and/or wiki, so I'll close this ticket. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1872#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1262: RecursiveDo in Template Haskell (was: mdo in Template Haskell)
by GHC 27 Jan '13

27 Jan '13

#1262: RecursiveDo in Template Haskell ----------------------------------------+----------------------------------- Reporter: philip.weaver@… | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.6 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------------+----------------------------------- Comment(by igloo): {{{ Prelude> :set -XRecursiveDo -XTemplateHaskell Prelude> :m + Language.Haskell.TH Prelude Language.Haskell.TH> do x <- runQ [| do rec { x <- return y; y <- return x }; return () |]; putStrLn (pprint x) <interactive>:4:17: Exotic statement not (yet) handled by Template Haskell [rec { x <- return y; y <- return x }, return ()] }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1262#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1298: Data.Complex.phase does unnecessary pattern match
by GHC 27 Jan '13

27 Jan '13

#1298: Data.Complex.phase does unnecessary pattern match -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Prelude | Version: 6.7 Resolution: invalid | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Yeah, I'll close this. Anyone interested in seeing it happen, please propose it on the list as per the policy. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1298#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1614: Type checker does not use functional dependency to avoid ambiguity
by GHC 27 Jan '13

27 Jan '13

#1614: Type checker does not use functional dependency to avoid ambiguity --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.7 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Comment(by igloo): If I understand correctly, it was chak's code that worked, not the code in the original description. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1614#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7616: ghci loading package base linking crash
by GHC 27 Jan '13

27 Jan '13

#7616: ghci loading package base linking crash -----------------------+---------------------------------------------------- Reporter: crabman | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.6.1 | Keywords: base Os: Windows | Architecture: x86_64 (amd64) Failure: GHCi crash | Blockedby: Blocking: | Related: -----------------------+---------------------------------------------------- I've just installed GHC and tried to run ghci, and it crashed and asked to report this as a bug. x86_64 windows 8 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7616> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1894: Add a total order on type constructors
by GHC 26 Jan '13

26 Jan '13

#1894: Add a total order on type constructors ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: 6.8.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------------+----------------------------------- Comment(by goldfire): As far as I can see, the evolution of the type system hasn't fundamentally changed this issue. With closed kinds (i.e., those from a promoted datatype), it is easy to define an ordering using a type family. But, that doesn't solve the problem for kind {{{*}}}. There is a chance that any applications that want this feature can use nfrisby's packages, or the upcoming TypeLits work, which includes type- level strings. Is there anyone out there who still needs this? What's your application? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1894#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0