- ghc-tickets - Haskell.org

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

Re: [GHC] #1831: reify never provides the declaration of variables
by GHC 26 Jan '13

26 Jan '13

#1831: reify never provides the declaration of variables ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.8.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by goldfire): * cc: eir@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1831#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1849: Template Haskell: reify is not consistent with the special constructors ListT and TupleT
by GHC 26 Jan '13

26 Jan '13

#1849: Template Haskell: reify is not consistent with the special constructors ListT and TupleT ------------------------------+--------------------------------------------- Reporter: guest | Type: bug Status: new | Priority: normal Milestone: _|_ | Component: Template Haskell Version: 6.8.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- Changes (by goldfire): * cc: eir@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1849#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0