June 2014 - ghc-tickets

[GHC] #9205: Deriving Typeable for poly-kinded data family gives confusing error message
by GHC 16 Jun '14

16 Jun '14

#9205: Deriving Typeable for poly-kinded data family gives confusing error message ------------------------------------+------------------------------------- Reporter: dfranke | 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 following works fine: {{{ {-# LANGUAGE TypeFamilies, DeriveDataTypeable, StandaloneDeriving #-} module Test where import Data.Typeable class Foo a where data family Bar a deriving instance (Typeable Bar) }}} However, if I add `-XPolyKinds`, I get a horribly confusing error: {{{ Test.hs:9:1: Can't make a derived instance of ‘Typeable Bar’: Deriving Typeable is not allowed for family instances; derive Typeable for ‘Bar’ alone In the stand-alone deriving instance for ‘Typeable Bar’ }}} The correct way to resolve the error is to add a monomorphic kind signature to Bar, e.g. `data family Bar (a :: *)`. Perhaps the error message could suggest this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9205> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #6024: Allow defining kinds alone, without a datatype
by GHC 16 Jun '14

16 Jun '14

#6024: Allow defining kinds alone, without a datatype --------------------------------------------+------------------------------ Reporter: dreixel | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by dreixel): * cc: diatchki@… (added) Comment: Iavor, you worked on this for a while, didn't you? What's the status? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6024#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 16 Jun '14

16 Jun '14

#7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by simonpj): The VOODOO CODING is of course wrong. Take a look at the version for `BindStmt` in (for example) `tcMcStmt`, in `TcMatches` line 511. We are typechecking `pat <- rhs; body` as if it was `(>>=) rhs (\x -> body)`. So we instantiate `(>>=)`, expecting its type to have the shape {{{ rhs_ty -> (pat_ty -> body_ty) }}} That's what `tcSyntaxOp` does. Then we check that `pat` really does have type `pat_ty` and `rhs` really does have type `rhs_ty`. Presumably you need to do similar things for arrows, but I'm not deep enough into it to know how. Doing the instantiation once, at `CmdTop` will almost certainly not work. I'm sorry not to be more helpful. Why not follow Ross's suggestions in comment 17? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9195: ImpredicativeTypes and ConstraintKinds don't interact as expected
by GHC 13 Jun '14

13 Jun '14

#9195: ImpredicativeTypes and ConstraintKinds don't interact as expected ----------------------------+---------------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Given this code: {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, ImpredicativeTypes, ConstraintKinds #-} class P a b instance P a b type Test a = forall b. P a b }}} I would expect to be able to actually use the Test Constraint in a function, like so: {{{ foo :: Test a => a -> a foo = id }}} But GHC complains that: {{{ Illegal polymorphic or qualified type: Test a In the type signature for ‘foo’: foo :: Test a => a -> a }}} I get the exact same error message if I replace ImpredicativeTypes with RankNTypes. If this is intended behavior under ImpredicativeTypes, how difficult would it be to add another extension that allows this type of polymorphism? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
by GHC 13 Jun '14

13 Jun '14

#1407: Add the ability to :set -l{foo} in .ghci files -------------------------------+------------------------------------------- Reporter: guest | Owner: archblob Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by archblob): * milestone: ⊥ => 7.10.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1407#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #95: GHCi :edit command should jump to the the last error
by GHC 13 Jun '14

13 Jun '14

#95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: lortabac martijnislief | Status: closed Type: feature | Milestone: ⊥ request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: None => fixed Comment: Thanks, Lorenzo, for your first contribution to GHC! I hope more will follow :-) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/95#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #95: GHCi :edit command should jump to the the last error
by GHC 13 Jun '14

13 Jun '14

#95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: lortabac martijnislief | Status: patch Type: feature | Milestone: ⊥ request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Joachim Breitner <mail@…>): In [changeset:"ce19d5079ea85d3190e837a1fc60000fbd82134d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ce19d5079ea85d3190e837a1fc60000fbd82134d" Fixes #95 :edit command should jump to the last error }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/95#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #95: GHCi :edit command should jump to the the last error
by GHC 13 Jun '14

13 Jun '14

#95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: lortabac martijnislief | Status: patch Type: feature | Milestone: ⊥ request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by nomeata): Don’t worry about test names, `prog013` is fine; `T95` would have been another possibility. Ideally, the test case is never looked at again, because nobody breaks this feature. The patch is, IMHO, good to go. I’m validating this right now and will push if validation succeeds. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/95#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 12 Jun '14

12 Jun '14

#6135: Unboxed Booleans ---------------------------------------------+----------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: primops/should_run/T6135 | Difficulty: Unknown Blocking: | Blocked By: 8103, | 8103 | Related Tickets: #605 ---------------------------------------------+----------------------------- Comment (by altaic): Replying to [comment:91 Lemming]: > Replying to [comment:90 carter]: > > @lemming, Bool# is now Int# afaik, could you explain what you mean? even if we used a i1 rep, it still needs a full register! So theres no lost for the in register rep to be Int#, afaik > > `Int#` represents a large range of integers, whereas `i1` in LLVM has only values 0 and 1. That is, LLVM can optimize based on the knowledge of the restricted value set of `i1`, but it certainly fails to do so on `i32` or `i64`. Two of the advantages in representing Bool# as an i1 is that llvm can vectorize them, and arrays of i1 can fit in an i32 or i64. Off the top of my head, I don't know of any software that makes use of large arrays of booleans, but in that case this sort of optimization would likely be very effective. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6135#comment:92> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7259: Eta expansion of products in System FC
by GHC 12 Jun '14

12 Jun '14

#7259: Eta expansion of products in System FC -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ekmett): * cc: ekmett@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7259#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0