- ghc-tickets - Haskell.org

Re: [GHC] #7650: can't use combining characters in identifiers
by GHC 23 Feb '16

23 Feb '16

#7650: can't use combining characters in identifiers -------------------------------------+------------------------------------- Reporter: guest | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 (Parser) | Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1938 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"2aee41960aa00fe09a2cd1983e02c15e06013037/ghc" 2aee419/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2aee41960aa00fe09a2cd1983e02c15e06013037" Allow combining characters in identifiers (#7650) Reviewed by: austin, rwbarton Differential Revision: https://phabricator.haskell.org/D1938 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7650#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5654: Profiling semantics bug
by GHC 23 Feb '16

23 Feb '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Fixed, sorry about that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11630: More precise LANGUAGE pragma when forall is used
by GHC 23 Feb '16

23 Feb '16

#11630: More precise LANGUAGE pragma when forall is used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In all cases when a user attempts to use the `forall` keyword, GHC suggests enabling `RankNTypes`. This seems suboptimal, since a more direct way to enable just the syntax is `ExplicitForAll`. So maybe we should just suggest that instead. In some cases, the user will immediately thereafter have to add `RankNTypes`, or `Rank2Types`, or `ExistentialQuantification`, etc. So it would be more user friendly to suggest the appropriate extension directly. I don't know how much harder this would be to do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11630> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11628: Unexpected results with Read/Show
by GHC 23 Feb '16

23 Feb '16

#11628: Unexpected results with Read/Show -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following simplified example, `Foo` and `U` correspond to GADTs that GHC will not derive `Read`/`Show` for. I attempted to work around that by using newtypes for each GADT constructor, and letting GHC derive the `Show`/`Read` instances for those instead. However, I get a runtime error (`Prelude.read: no parse`) on the second print statement in `main`: {{{ {-# LANGUAGE FlexibleContexts, FlexibleInstances, GADTs, ScopedTypeVariables #-} import Text.Read (Read(readPrec)) newtype Bar r = Bar r deriving (Show, Read) newtype Foo r = Foo (Bar r) -- use the GHC-derived Show/Read for Bar instance (Show r) => Show (Foo r) where show (Foo x) = show x instance (Read r) => Read (Foo r) where readPrec = Foo <$> readPrec data U t rep r where U1 :: t r -> U t Int r U2 :: t r -> U t Char r -- use the Read/Show instances for U1Wrap and U2Wrap newtype U1Wrap t r = U1Wrap {unU1Wrap :: t r} deriving (Show, Read) newtype U2Wrap t r = U2Wrap (t r) deriving (Show, Read) instance (Read (t r)) => Read (U t Int r) where readPrec = (U1 . unU1Wrap) <$> readPrec instance (Read (U2Wrap t r)) => Read (U t Char r) where readPrec = do x <- readPrec return $ case x of (U2Wrap y) -> U2 y instance (Show (t r)) => Show (U t Int r) where show (U1 x) = show $ U1Wrap x instance (Show (t r)) => Show (U t Char r) where show (U2 x) = show (U2Wrap x :: U2Wrap t r) main :: IO () main = do let x = U1 $ Foo $ Bar 3 y = U2 $ Foo $ Bar 3 print $ show (read (show x) `asTypeOf` x) print $ show (read (show y) `asTypeOf` y) }}} Someone mentioned that I should define `showsPrec` rather than `show`, but these are listed as alternatives in [https://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.8.2.0 /Text-Show.html the docs]. It's not clear to me if GHCs derived instances are invalid, or if I'm doing something illegal. In the latter case, the docs need some improvement. (Verified this behavior in 7.10.2 and HEAD.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11628> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #5654: Profiling semantics bug
by GHC 23 Feb '16

23 Feb '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Simon: in 85daac593c498f581d46f44982ee5dcf1001f611, you defined two new tests (`T5654b-O0` and `T5654b-O0`), but didn't add `.hs` files for them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment
by GHC 22 Feb '16

22 Feb '16

#11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.3 Haskell | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `Language.Haskell.TH.Syntax` it reads on the generation of fresh names: {{{ Although names generated by @newName@ cannot /be captured/, they can /capture/ other names. For example, this: >g = $(do > nm1 <- newName "x" > let nm2 = mkName "x" > return (LamE [VarP nm2] (LamE [VarP nm1] (VarE nm2))) > ) will produce the splice >g = \x -> \x0 -> x0 since the occurrence @VarE nm2@ is captured by the innermost binding of @x@, namely @VarP nm1@. }}} I find this note quite misleading, especially since the above splice normally generates something like {{{ \ x -> \ x_a3vv -> x }}} where no inadvertent capture occurs. I belive this note should rather be something as follows: {{{ Although names generated by @newName@ cannot /be captured/, they can /capture/ other names. For example, suppose that the next invocation of newName would generate the name nm1 = x0, and we have the following splice, where mkName uses the very same name x0 for nm2: >g = $(do > nm1 <- newName "x" > let nm2 = mkName "x0" > return (LamE [VarP nm2] (LamE [VarP nm1] (VarE nm2))) > ) This will produce the following splice, where nm1 generated by newName captures nm2 assigned by mkName: >g = \x0 -> \x0 -> x0 In particular, now the occurrence @VarE nm2@ is captured by @VarP nm1@ and not by @VarP nm2" anymore (as was intended by the TH AST). }}} I'm happy to change this, if people agree :-). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11584> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #2289: Needless reboxing of values when returning from a tight loop
by GHC 22 Feb '16

22 Feb '16

#2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, | loops, performance Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2387,#1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, nested CPR would be great. See [wiki:NestedCPR] for Joachim's writeup of his work on it; lots of stuff there. Re one-specialisation: `SpecConstr` is free to generate lots of specialisations. But the demand analyser does not make many copies of a function, one for each demand pattern. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2289#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11613: Add microlens to testsuite
by GHC 22 Feb '16

22 Feb '16

#11613: Add microlens to testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `microlens` package on Hackage seems to be a very good stress test for the typechecker while having few dependencies. We should consider adding it to the testsuite. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11613> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7644: Hackage docs for base library contain broken links
by GHC 22 Feb '16

22 Feb '16

#7644: Hackage docs for base library contain broken links -------------------------------------+------------------------------------- Reporter: JulesBean | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): There are still many dead links. For example the link to `par` on the page http://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GHC-Magic.html. I guess it has something to do with `parallel` not being built by default. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7644#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11620: RFC: Type-class type signatures (:: Constraint)
by GHC 22 Feb '16

22 Feb '16

#11620: RFC: Type-class type signatures (:: Constraint) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Data types can be defined: {{{#!hs data A a b -- or data A (a :: Bool) (b :: Type) -- or data A (a :: Bool) (b :: Type) :: Type -- or data A :: Bool -> Type -> Type data B :: Type }}} while type classes can't: {{{#!hs class A a b -- or class A (a :: Bool) (b :: Type) -- but not -- class A (a :: Bool) (b :: Type) :: Constraint -- nor -- class A :: Bool -> Type -> Constraint -- class B :: Constraint }}} I foresee problems with how to bind `a` and `b`, but adding a final `:: Constraint` should be legal: {{{#!hs class A a b :: Constraint class A (a :: Bool) (b :: Type) :: Constraint class B :: Constraint }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11620> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2