March 2017 - ghc-tickets

[GHC] #13279: Check known-key lists
by GHC 19 Sep '18

19 Sep '18

#13279: Check known-key lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed that `fmap` (for example) has a known key {{{#!hs fmapName = varQual gHC_BASE (fsLit "fmap") fmapClassOpKey fmapClassOpKey = mkPreludeMiscIdUnique 173 }}} but its `RdrName` doesn't refer to it. {{{#!hs fmap_RDR = varQual_RDR gHC_BASE (fsLit "fmap") }}} Is there a reason for this? If not, it seems likely that we could get a bit of a speed-up by using `fmapName` here. We may also consider making `liftA2` known-key for `Traversable` deriving. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11284: Lambda-lifting fails in simple Text example
by GHC 18 Sep '18

18 Sep '18

#11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- Consider the example, {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11284> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10859: Generated Eq instance associates && wrongly
by GHC 18 Sep '18

18 Sep '18

#10859: Generated Eq instance associates && wrongly -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10858 Differential Revisions: | -------------------------------------+------------------------------------- Currently, we derive this code for `(==)`: {{{ (==) (ImportDecl a1_acXi a2_acXj a3_acXk a4_acXl a5_acXm a6_acXn a7_acXo a8_acXp) (ImportDecl b1_acXq b2_acXr b3_acXs b4_acXt b5_acXu b6_acXv b7_acXw b8_acXx) = (((((((((a1_acXi == b1_acXq)) && ((a2_acXj == b2_acXr))) && ((a3_acXk == b3_acXs))) && ((a4_acXl == b4_acXt))) && ((a5_acXm == b5_acXu))) && ((a6_acXn == b6_acXv))) && ((a7_acXo == b7_acXw))) && ((a8_acXp == b8_acXx))) }}} To me this looks wrongly associated: Since `&&` is strict in the left but lazy in the right argument, shouldn’t this be associated the other way around? The compiler might clean it up later, but why not produce it correctly right away? The culprit is this line: {{{ = foldl1 and_Expr (zipWith3Equal "nested_eq" nested_eq tys as bs) }}} and I was just about to change that ot `foldr1`, but then I did some git- archeology and found that Simon changed that deliberately from `foldr1` to `foldl1` in changeset:8de16184643ea3c2f9f30b5eaed18db6ef247760. Simon, do you still recall what you were thinking when you applied this commit ... 18½years ago? :-) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10859> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12457: Deriving should be (more closely) integrated with other metaprogramming methods
by GHC 17 Sep '18

17 Sep '18

#12457: Deriving should be (more closely) integrated with other metaprogramming methods -------------------------------------+------------------------------------- Reporter: mpickering | Owner: 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: -------------------------------------+------------------------------------- It is unfortunate that if we want to (efficiently) derive a new type class then we have to bake the derivation logic into GHC itself. It seems desirable to be able to implement new deriving methods in libraries in some manner. Ryan Scott says: > I think this would be a wonderful thing to have. Matthew Pickering > (cc'd) has expressed a desire to have all the logic for the `bespoke` > deriving strategies compartmentalized into a library that could easily > be expanded on in the future to support more typeclasses in base. > (Bifunctor, anyone?) > > Unfortunately, each of the major players in today's Haskell > metaprogramming scene that I'm aware of have some downfalls that make > them unsuitable as `deriving` replacements: > > * Template Haskell: Not portable. Staging issues make it hard to use as a drop-in replacement for the `deriving` keyword > * GHC generics: Can't express all the optimizations that the bespoke `deriving` algorithms perform. Unperformant. > * Haskell preprocessors: Difficult to integrate in a typical GHC workflow. Probably wouldn't have all the metadata you'd need to be feature-complete with what `deriving` does today. > > The way I see it, the whole `deriving` business as it currently stands > today is a somewhat-grotesque-but-darn-useful hack that gets around > the lack of a truly nice metaprogramming facility in Haskell. I'm > holding out hope that the work in > https://github.com/shayan-najd/NativeMetaprogramming makes things > nicer soon, and then we can revisit this idea. Until then, > -XDerivingStrategies provides a way to contain some of the madness of > `deriving` after having many features tacked onto it in recent GHC > releases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12457> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10651: Type checking issue with existential quantification, rank-n types and constraint kinds
by GHC 16 Sep '18

16 Sep '18

#10651: Type checking issue with existential quantification, rank-n types and constraint kinds -------------------------------------+------------------------------------- Reporter: Roboguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm trying to create a library for working with lists with existentially quantified types and I ran into an issue implementing `mapM_` for my type (note that the `map` and `mapM` implementations both work fine): {{{#!hs {-# LANGUAGE RankNTypes, ExistentialQuantification, ConstraintKinds #-} data ConstrList c = forall a. c a => a :> ConstrList c | CNil infixr :> constrMap :: (forall a. c a => a -> b) -> ConstrList c -> [b] constrMap f (x :> xs) = f x : constrMap f xs constrMap f CNil = [] constrMapM :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m [b] constrMapM f = sequence . constrMap f -- Doesn't work, even with the definition as undefined (?) constrMapM_ :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m () constrMapM_ = undefined }}} It fails with this error message: {{{ /users/dyoung/Test.hs:16:16: Couldn't match type ‘b0’ with ‘b’ ‘b0’ is untouchable inside the constraints (c a) bound by the type signature for constrMapM_ :: c a => a -> m b0 at /users/dyoung/Test.hs:16:16-77 ‘b’ is a rigid type variable bound by the type signature for constrMapM_ :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m () at /users/dyoung/Test.hs:16:16 Expected type: a -> m b0 Actual type: a -> m b In the ambiguity check for the type signature for ‘constrMapM_’: constrMapM_ :: forall (c :: * -> Constraint) (m :: * -> *) b. Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m () To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ‘constrMapM_’: constrMapM_ :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m () Failed, modules loaded: none. }}} If I add `AllowAmbiguousTypes`, it works when the definition is `undefined` but it doesn't work if I put the real definition in. I believe that this is accepted and works as I had intended on 7.8.3 (with the correct definition as well) after talking to some people on IRC, but I haven't personally tested it. bitemyapp on IRC noticed that it does compile on 7.10.1 if we add an extra argument of type `b` to both `constrMap_` and `constrMapM` and pass that value from `constrMapM_` to `constrMap` (I think all of those things must happen in order for this to work): {{{#!hs constrMapM :: Monad m => b -> (forall a. c a => a -> m b) -> ConstrList c -> m [b] constrMapM ignoredB f = sequence . constrMap f constrMapM_ :: Monad m => b -> (forall a. c a => a -> m b) -> ConstrList c -> m () constrMapM_ b f xs = fmap (const ()) (constrMapM b f xs) }}} Is this expected behavior? I don't fully understand the new ambiguity check. This kind of reminds me of linear types (or a relevant type system) in a way: we must make explicit use of the `b` to "discharge" it in order to have a valid type. Also, I notice that this works fine as well, which makes me think it the type error above is related to `ConstraintKinds`: {{{#!hs data AnyList f = forall a. (f a) :| (AnyList f) | Nil infixr :| anyMap :: (forall a. f a -> b) -> AnyList f -> [b] anyMap f (x :| xs) = f x : anyMap f xs anyMap _ Nil = [] anyMapM :: Monad m => (forall a. f a -> m b) -> AnyList f -> m [b] anyMapM f xs = sequence (anyMap f xs) anyMapM_ :: Monad m => (forall a. f a -> m b) -> AnyList f -> m () anyMapM_ f xs = fmap (const ()) (anyMapM f xs) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10651> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12565: unhelpful error message about enabling TypeApplications
by GHC 14 Sep '18

14 Sep '18

#12565: unhelpful error message about enabling TypeApplications -------------------------------------+------------------------------------- Reporter: mauke | Owner: 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: -------------------------------------+------------------------------------- {{{ % cat bug.hs }}} {{{#!hs {-# LANGUAGE TypeApplications #-} main = return (id@() ()) }}} {{{ % ghc bug.hs [1 of 1] Compiling Main ( bug.hs, bug.o ) bug.hs:2:16: error: Pattern syntax in expression context: id@() Did you mean to enable TypeApplications? }}} This error message makes no sense because `TypeApplications` is already enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12565> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray#
by GHC 14 Sep '18

14 Sep '18

#11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- Currently, primops for indexing `ByteArray#` and reading/writing `MutableByteArray#` have the following form: {{{#!hs indexTYPEArray# :: ByteArray# -> Int# -> TYPE# readTYPEArray# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, TYPE##) writeTYPEArray# :: MutableByteArray# s -> Int# -> TYPE# -> State# s -> State# s }}} where second argument of type `Int#` is an offset measured in terms of the size of `TYPE#`. This is inconvinient if I want to store values of different types inside `ByteArray#`: I have to read values of type `Int8` and then glue them together with some bitwise operations. I suggest adding number of primops, similar to existing ones, which would accept offset in bytes from the start of the `ByteArray#`: {{{#!hs -- | Read 8-bit integer; offset in bytes. indexByteInt8Array# :: ByteArray# -> Int# -> Int# -- | Read 16-bit integer; offset in bytes. indexByteInt16Array# :: ByteArray# -> Int# -> Int# -- | Read 32-bit integer; offset in bytes. indexByteInt32Array# :: ByteArray# -> Int# -> Int# -- | Read 8-bit integer; offset in bytes. readInt8Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##) -- | Read 16-bit integer; offset in bytes. readInt16Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##) -- | Read 32-bit integer; offset in bytes. readInt32Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##) }}} and so on... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10700: include/stg/Prim.h isn't C++ compatible
by GHC 14 Sep '18

14 Sep '18

#10700: include/stg/Prim.h isn't C++ compatible -------------------------------------+------------------------------------- Reporter: Fabian | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Keywords: FFI | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- StgWord hs_cmpxchg8(volatile StgWord8 *x, StgWord old, StgWord new); and a few other declarations in Prim.h causes problems as they use ''new'' as a variable name. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10833: Use injective type families when dealing with givens
by GHC 14 Sep '18

14 Sep '18

#10833: Use injective type families when dealing with givens -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #6018 Differential Revisions: | -------------------------------------+------------------------------------- Consider this code: {{{#!hs type family Id a = r | r -> a id :: (Id a ~ Id b) => a -> b id x = x }}} GHC currently rejects it because it does not use type family injectivity information when dealing with the given constraints. Implementing this requires changing Core. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10833> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12420: Users guide link for hsc2hs has bitrotten
by GHC 13 Sep '18

13 Sep '18

#12420: Users guide link for hsc2hs has bitrotten -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: hsc2hs | 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: -------------------------------------+------------------------------------- https://hackage.haskell.org/package/hsc2hs links to http://www.haskell.org/ghc/docs/latest/html/users_guide/hsc2hs.html which is dead. I think https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/utils.html #writing-haskell-interfaces-to-c-code-hsc2hs is what is desired. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12420> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2