August 2017 - ghc-tickets

[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] #13862: Optional "-v" not allowed with :load in GHCi
by GHC 16 Sep '18

16 Sep '18

#13862: Optional "-v" not allowed with :load in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When loading a file in GHCi with the command {{{:load}}} and the file must import another file, if that other file is unavailable then GHCi sends the following error\\ {{{ Failed to load interface for `xxx` Use -v to see a list of the files searched for. }}} ' xxx ' is the name of the imported file that GHCi cannot find.\\ But we can not use a flag ( ie -v) with the command {{{:load}}} in GHCi.\\ This error is not appropriate in GHCi when using {{{:load}}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13862> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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] #14099: Document fundeps
by GHC 14 Sep '18

14 Sep '18

#14099: Document fundeps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Keywords: newcomers | 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 the documentation for functional dependencies in the GHC user's guide is quite poor. Fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14099> 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

[GHC] #14025: Object file is put in wrong directory when any source has absolute path
by GHC 13 Sep '18

13 Sep '18

#14025: Object file is put in wrong directory when any source has absolute path -------------------------------------+------------------------------------- Reporter: literon | 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: -------------------------------------+------------------------------------- Files: `/tmp/e/A.hs`, `/tmp/e/dep.c`. Current dir: `/tmp/e`. `ghc -odir /tmp/xyzzy A.hs dep.c`: works as expected, puts `dep.o` in `/tmp/xyzzy`. But try to prefix either `A.hs` or `dep.c` (or both) with `/tmp/e/`, and suddenly `dep.o` is put in `/tmp/e`, not in `/tmp/xyzzy`. Couldn't check with 8.2.1 yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14025> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8