May 2017 - ghc-tickets

[GHC] #13713: fdefer-type-errors makes missing import errors disappear
by GHC 18 May '17

18 May '17

#13713: fdefer-type-errors makes missing import errors disappear -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12529 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have this code {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} import Data.Type.Equality ((:~:)(Refl)) import GHC.TypeLits import qualified Numeric.LinearAlgebra as LA import Numeric.LinearAlgebra.Static toVec :: forall n . (KnownNat n) => LA.Vector Double -> R n toVec vec = withVector vec $ \(v :: R n2) -> case sameNat (Proxy @n) (Proxy @n2) of Just Refl -> v Nothing -> error "wrong dimensions" }}} Notably I forgot to import `Proxy`. Without `-fdefer-type-errors` I get this error: {{{ ➤ nix-shell -p "haskellPackages.ghcWithPackages (pkgs:[pkgs.hmatrix])" --pure --run 'ghci ghc-8.0.2-proxy-confusing-error.hs' GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ghc-8.0.2-proxy-confusing-error.hs, interpreted ) ghc-8.0.2-proxy-confusing-error.hs:12:60: error: Data constructor not in scope: Proxy ghc-8.0.2-proxy-confusing-error.hs:12:60: error: * Cannot apply expression of type `t1' to a visible type argument `n' * In the first argument of `sameNat', namely `(Proxy @n)' In the expression: sameNat (Proxy @n) (Proxy @n2) In the expression: case sameNat (Proxy @n) (Proxy @n2) of { Just Refl -> v Nothing -> error "wrong dimensions" } Failed, modules loaded: none. }}} but with `-fdefer-type-errors` the `Data constructor not in scope: Proxy` is gone! {{{ ➤ nix-shell -p "haskellPackages.ghcWithPackages (pkgs:[pkgs.hmatrix])" --pure --run 'ghci ghc-8.0.2-proxy-confusing-error.hs -fdefer-type-errors' GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ghc-8.0.2-proxy-confusing-error.hs, interpreted ) ghc-8.0.2-proxy-confusing-error.hs:12:60: error: * Cannot apply expression of type `t1' to a visible type argument `n' * In the first argument of `sameNat', namely `(Proxy @n)' In the expression: sameNat (Proxy @n) (Proxy @n2) In the expression: case sameNat (Proxy @n) (Proxy @n2) of { Just Refl -> v Nothing -> error "wrong dimensions" } Failed, modules loaded: none. }}} This is probably related to #12529. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13712: Attach size to ForeignPtr
by GHC 17 May '17

17 May '17

#13712: Attach size to ForeignPtr -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- In some types of programs the dominant memory consumer is foreign objects whose lifetime is controlled by `ForeignPtr`s. In these cases the heuristics used by the GC don't reflect the true heap size of the process, meaning that garbage collection doesn't happen as often as it should. One suggested approach to alleviating this is to allow users to tell the GC about the size of the object represented by a `ForeignPtr`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13712> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7395: DefaultSignatures conflict with default implementations
by GHC 17 May '17

17 May '17

#7395: DefaultSignatures conflict with default implementations -------------------------------------+------------------------------------- Reporter: cgaebel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: | DefaultSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 7346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:19 aspiwack]: > I found myself, today, in a situation where I wanted to have two default signatures, something like: You might be interested in [https://gist.github.com/Icelandjack/e1ddefb0d5a79617a81ee98c49fbbdc4 an idea] I'm developing, {{{#!hs newtype WrapInt = WrapInt Int newtype WrapBool = WrapBool Bool instance Foo WrapInt where foo :: WrapInt foo = WrapInt 0 instance Foo WrapBool where foo :: WrapBool foo = WrapBool False }}} and you should be able to derive {{{#!hs newtype I = MkI Int deriving as WrapInt (Foo) newtype B = MkB Bool deriving as WrapBool (Foo) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7395#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11439: Request for comments: Allow duplicate type signatures
by GHC 17 May '17

17 May '17

#11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Interested in feedback (Code inspired by [http://www.cs.ox.ac.uk/projects/utgp/school/idris-tutorial.pdf Idris tutorial]) {{{#!hs sum :: SBool single -> IsSingleton single -> Natural sum STrue x = x sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} Allow duplicate type signatures: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural sum :: SBool True -> Natural -> Natural sum STrue x = x sum :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} Where {{{#!hs data SBool b where STrue :: SBool True SFalse :: SBool False type family IsSingleton (b :: Bool) :: Type where IsSingleton True = Natural IsSingleton False = [Natural] }}} ---- == Behaviour == You could do something fancy but I would be happy with a check that any duplicate type signature is a specialization of the ''top'' top-level one, this would allow something like this: {{{#!hs length :: [a] -> Int length :: [()] -> Int length [] = 0 length (_:xs) = 1 + length xs }}} Which isn't very useful, hah what ever. ---- == Benefits == Mainly compiler-checked documentation, for the `sum` function we make it clearer that a `STrue` gives you `Natural -> Natural` while `SFalse` gives you `[Natural] -> Natural`. This is most apparent in the final syntax idea: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural @True :: _ -> Natural -> Natural @False :: _ -> [Natural] -> Natural }}} Reader need not look at definition of `IsSingleton`, it is fully described by the duplicate signatures. See ''lens'' where most functions have some kind of type specialisation declared in comments: [https://hackage.haskell.org/package/lens-4.13/docs /Control-Lens-Fold.html#v:-94--63- (^?)] whose type is `(^?) :: s -> Getting (First a) s a -> Maybe a`: {{{#!hs (^?) :: s -> Getter s a -> Maybe a (^?) :: s -> Fold s a -> Maybe a (^?) :: s -> Lens' s a -> Maybe a (^?) :: s -> Iso' s a -> Maybe a (^?) :: s -> Traversal' s a -> Maybe a }}} ---- == Alternative syntax == Throwing it out there, regardless of ambiguity: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural :: SBool True -> Natural -> Natural sum STrue x = x :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural ... :: SBool True -> Natural -> Natural sum STrue x = x ... :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural ... @True :: _ -> Natural -> Natural sum STrue x = x ... @False :: _ -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural @True :: _ -> Natural -> Natural sum STrue x = x @False :: _ -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7395: DefaultSignatures conflict with default implementations
by GHC 17 May '17

17 May '17

#7395: DefaultSignatures conflict with default implementations -------------------------------------+------------------------------------- Reporter: cgaebel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: | DefaultSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 7346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aspiwack): I found myself, today, in a situation where I wanted to have two default signatures, something like: {{{#!haskell {-# LANGUAGE DefaultSignatures #-} module Test where class Foo a where foo :: a default foo :: (a~Int) => a foo = 0 default foo :: (a~Bool) => a foo = False }}} The practical situation was that the second default implementation requires an extra `MonadIO m` constraint and is more efficient. My proposal is to resolve default implementation like overlapping instances: the default with the most specific type amongst the well-typed ones is used. The compiler can check, when creating the class that default implementations of a same method either don't unify or are strictly ordered with the specialisation order. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7395#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13679: Kill eqIfaceType
by GHC 16 May '17

16 May '17

#13679: Kill eqIfaceType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- `IfaceType.eqIfaceType` seems to be dead code. Can we kill it? It appears to be something to do with backpack. It would be good to kill it because eqType is subtle. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13679> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13698: Add a more complete example for the special SPEC argument to the user guide
by GHC 16 May '17

16 May '17

#13698: Add a more complete example for the special SPEC argument to the user guide -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: SpecConstr Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the section for `-fspec-constr` in the user guide there is an example of how to use `SPEC` to force a loop to be unrolled by spec constr. However, this argument doesn't do anything until `foldl` is called with a specific argument. It wasn't clear to me exactly how this worked as the example was incomplete. Below is a complete file which shows how the optimisation unrolls the list completely such that `res2 = 6` in core. {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE ExistentialQuantification #-} module Foo where import GHC.Types data Stream a = forall s. Stream !(s -> Step a s) -- a stepper function !s -- an initial state data Step a s = Yield a !s | Skip !s | Done s2 = Stream s [1,2,3] s [] = Done s (x:xs) = Yield x xs res2 = Foo.foldl (+) 0 s2 foldl :: (a -> b -> a) -> a -> Stream b -> a {-# INLINE foldl #-} foldl f z (Stream step s) = foldl_loop SPEC z s where foldl_loop !sPEC z s = case step s of Yield x s' -> foldl_loop sPEC (f z x) s' Skip s' -> foldl_loop sPEC z s' Done -> z }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13698> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13694: CSE runs before SpecConstr
by GHC 16 May '17

16 May '17

#13694: CSE runs before SpecConstr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: SpecConstr, | Operating System: Unknown/Multiple cse | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- SpecConstr can lead to more CSE opportunities. Currently CSE is run only once after the full laziness transformation but then not again later in the pipeline. Running it again after the final clean-up simplification might lead to smaller programs. One example with `-fspec-constr-keen`. {{{ module Foo where main :: [Int] main = drop 1 [1,2] mainMODULE :: [Int] mainMODULE = mydrop 1 [1,2] mydrop :: Int -> [a] -> [a] mydrop 0 xs = xs mydrop n (x:xs) = mydrop (n-1) xs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13694> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13309: Use liftA2 in ApplicativeDo
by GHC 16 May '17

16 May '17

#13309: Use liftA2 in ApplicativeDo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Now that `liftA2` is in `Applicative`, we want to be sure to use it when desugaring `ApplicativeDo`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13309> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13664: Ill formatted warning about tabulators
by GHC 16 May '17

16 May '17

#13664: Ill formatted warning about tabulators -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 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: -------------------------------------+------------------------------------- GHC-8.2.0.20170505 does not format warnings about tabulators very well. It seems to use the tab character for formatting, which yields too few spaces when formatted, and in turn too many characters are colored. (It is hard to present the problem in this ticket, though.) {{{ $ cat Tabulator.hs module Tabulator where x :: Int x = 1*2*3*4*5*6*7*8*9 -- we use a tab for indentation here $ ghc-8.2.0.20170505 -Wall Tabulator.hs [1 of 1] Compiling Tabulator ( Tabulator.hs, Tabulator.o ) Tabulator.hs:5:1: warning: [-Wtabs] Tab character found here. Please use spaces instead. | 5 | 1*2*3*4*5*6*7*8*9 | ^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13664> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6