- ghc-tickets - Haskell.org

Re: [GHC] #5902: Cannot tell from an exception handler whether the exception was asynchronous
by GHC 17 Jun '14

17 Jun '14

#5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.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 liyang): * cc: hackage.haskell.org@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5902#comment:26> 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): I wrote > 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`. The last sentence is terribly important! We are not just checking that `(>>=)` has a type of the right shape (which is, I gather from your question, what you think is going on), ''but also that it's type can be instantiated to match the particular pattern `pat` and the particular rhs `rhs`''. You aren't doing that with `(>>>)` which is why you have all those uninstantiated type variables. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:29> 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 ross): Replying to [comment:27 jstolarek]: > > Why not follow Ross's suggestions in comment 17? > > If I understand correctly Ross' proposal is actually independent of this ticket: we could implement it and still have broken RebindableSyntax. That's why I chose to fix the rebindable syntax first. Perhaps then we can think about alternative desugaring of arrow syntax. It's not so much an alternative desugaring as a different view of the existing desugaring in which `do` and `if` can be rebound in an analogous manner to the way they're rebound in the expression world. Or it's a re- interpretation of this ticket: instead of using private versions of `arr`, `>>>` and `first`, the idea is to use private versions of the control operators `bind`, `bind_` and `ifThenElseA`, the arrow counterparts of `>>=`, `>>` and `ifThenElse`. I don't see how the former can work, as each language construct is translated to several of those combinators. In addition, you have less control of the types of these things, because the translation re-arranges and trims the environment it passes through the arrow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:28> 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 jstolarek): > Why not follow Ross's suggestions in comment 17? If I understand correctly Ross' proposal is actually independent of this ticket: we could implement it and still have broken RebindableSyntax. That's why I chose to fix the rebindable syntax first. Perhaps then we can think about alternative desugaring of arrow syntax. > The VOODOO CODING is of course wrong. Well, it is wrong, but I don't yet see why it is wrong. In my code I intended to check that `arr` has type `b -> c -> x b c` (where `x` is an arrow): {{{ arr_op' <- tcSyntaxOp DoOrigin arr_op (mkFunTy (mkFunTy b c) (mkCmdArrTy env b c)) }}} and that `>>>` has type `x a b -> x b c -> x a c`: {{{ compose_op' <- tcSyntaxOp DoOrigin compose_op (mkFunTys [mkCmdArrTy env a b, mkCmdArrTy env b c] (mkCmdArrTy env a c)) }}} I looked at the code you pointed me to and I don't yet see where I went wrong. Do you mean that I should not only check `arr` and `>>>` independently of everything else, but should also check that the type of the whole desugared expression - ie. `arr (\p -> ((xs),())) >>> c'` - is also correct? > Doing the instantiation once, at CmdTop will almost certainly not work. Not sure if I understand what instantiation you mean. You refer to `arr` and `compose`? They are instantiated separately for each data constructor that needs them. `HsCmdTop` was just an example. At the moment I implemented your proposal: every constructor stores operators required for its desugaring and the `CmdSyntaxTable` has been removed. Typechecking is the missing part. I'll be taking a stab at it sometime later this week. There are some examples of typechecking arrows in `TcArrows`, which will hopefully get me on the right track. Once this is done I expect to get tons of minor bugs resulting from my voodoo programming. Hopefully, these will be easy to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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