- ghc-tickets - Haskell.org

Re: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax
by GHC 02 Feb '13

02 Feb '13

#2530: deriving Show adds extra parens for constructor with record syntax ---------------------------------+------------------------------------------ Reporter: spl | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by morabbin): I don't think that the fact that [http://hackage.haskell.org/trac/haskell- prime/wiki/StricterLabelledFieldSyntax the GHC variant] wasn't voted suprem justifies making what is really just a cosmetic change. The case for change is pretty weak, since the GHC variant (with parens) is not at all ambiguous (clarity is next to godliness, etc,), and is semantically equivalent to the Hugs/Haskell 98 variant. Close as wontfix, I say! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2530#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2548: validate should continue if it sees warnings or haddock failures
by GHC 02 Feb '13

02 Feb '13

#2548: validate should continue if it sees warnings or haddock failures ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Build System | Version: 6.8.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by morabbin): This seems fixed now? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2548#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #709: "Fixup too large" error with -fasm on PowerPC
by GHC 02 Feb '13

02 Feb '13

#709: "Fixup too large" error with -fasm on PowerPC ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: low | Milestone: 6.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: powerpc Failure: Building GHC failed | Difficulty: Moderate (less than a day) Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Comment(by PHO): I rebased my [https://github.com/phonohawk/ghc/commit/aa1d7d35ac27625c9aa67fe71c186f79600… second] and [https://github.com/phonohawk/ghc/commit/3cedbfb49996da2f029b4a84ca39f4d21f3… third patch]: {{{ % git fetch http://github.com/phonohawk/ghc.git ticket-709 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/709#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7459: deriving Generic does not work with TypeLits
by GHC 02 Feb '13

02 Feb '13

#7459: deriving Generic does not work with TypeLits ---------------------------------+------------------------------------------ Reporter: maxtaldykin | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by nathanhowell): * cc: nathanhowell@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7459#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2456: For higher kinds, instance declarations need quantification in the context
by GHC 02 Feb '13

02 Feb '13

#2456: For higher kinds, instance declarations need quantification in the context -------------------------------+-------------------------------------------- Reporter: ronwalf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.9 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: x86 Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by goldfire): In response to the type system question: Essentially, yes, if something is expressible in FC, then it must* be good. But, I know of two loopholes in FC: unsafe coercions (we all knew that), and the !GeneralizedNewtypeDeriving bug (see #1496, #4846, which seem, to me, to be duplicates). *FC is a complicated beast these days, and though we've proved it type- safe in theory, we can't be sure in practice. :) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2456#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2456: For higher kinds, instance declarations need quantification in the context
by GHC 02 Feb '13

02 Feb '13

#2456: For higher kinds, instance declarations need quantification in the context -------------------------------+-------------------------------------------- Reporter: ronwalf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.9 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: x86 Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by morabbin): * failure: => None/Unknown * os: MacOS X => Unknown/Multiple Comment: Once one adds {{{ {-# LANGUAGE OverlappingInstances, TypeOperators, StandaloneDeriving, MultiParamTypeClasses, FlexibleInstances, DeriveDataTypeable #-} }}} 7.6.1 yields: {{{ 1 of 1] Compiling DerivingError ( DerivingError.hs, interpreted ) DerivingError.hs:81:1: Duplicate type signature: DerivingError.hs:81:1-33: $tExpr :: Data.Data.DataType DerivingError.hs:80:1-35: $tExpr :: Data.Data.DataType DerivingError.hs:81:1: Duplicate type signature: DerivingError.hs:81:1-33: $cIn :: Data.Data.Constr DerivingError.hs:80:1-35: $cIn :: Data.Data.Constr }}} Is this the expected behavior? Type system question: do we know that all of these extensions play nicely in a type-theoretic sense? Is the argument that, since they're all expressible in System F_C, we're okay? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2456#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2496: Invalid Eq/Ord instances in Data.Version
by GHC 02 Feb '13

02 Feb '13

#2496: Invalid Eq/Ord instances in Data.Version ---------------------------------+------------------------------------------ Reporter: guest | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.8.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: duncan.coutts@… => duncan -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2496#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2496: Invalid Eq/Ord instances in Data.Version
by GHC 02 Feb '13

02 Feb '13

#2496: Invalid Eq/Ord instances in Data.Version ---------------------------------+------------------------------------------ Reporter: guest | Owner: duncan.coutts@… Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.8.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by morabbin): * failure: => None/Unknown Comment: `Data.Version` in `base-4.6.0.1` still has the quoted instance for `Eq`. Not clear if there's been a library proposal. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2496#comment:5> 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 02 Feb '13

02 Feb '13

#1849: Template Haskell: reify is not consistent with the special constructors ListT and TupleT ---------------------------------+------------------------------------------ Reporter: guest | Type: bug Status: closed | Priority: normal Milestone: _|_ | Component: Template Haskell Version: 6.8.1 | Resolution: fixed Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: T1849 Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * testcase: => T1849 * resolution: => fixed Comment: I don't think there's any current plan to remove `ListT` and `TupleT`, but we now get the desired output in HEAD. I've added a test. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1849#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7353: Make system IO interruptible on Windows
by GHC 02 Feb '13

02 Feb '13

#7353: Make system IO interruptible on Windows ---------------------------------+------------------------------------------ Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Keywords: | Os: Windows Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by joeyadams): * blockedby: 7415 => Comment: I don't have time to work on this right now. It's more complicated than I expected: * Making the IOCP approach efficient would involve integration with the scheduler and a better understanding of how IOCP interacts with OS threads. * Couldn't switch to nonblocking sockets by [https://github.com/haskell/network/pull/79 modifying the network package alone], as GHC doesn't actually support custom IO devices. Some Handle methods cast the device to FD so they can read/write directly from/to the device; see #4144 . -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7353#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0