August 2016 - ghc-tickets

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 16 Aug '16

16 Aug '16

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:31 Iceland_jack]: > > {{{#!hs > data LanO j where > LanO :: LanO (S i) > > data LanS j where > LanS :: Fin i -> LanS (S i) > }}} > > `Fin` defined as > Do `LanO`, `LanS` satisfy the conditions to be newtypes? `LanO` does not, because its constructor takes no arguments. But that's perfectly fine; there's only one `LanO` value anyway. `LanS` does not either, because its constructor is lazy. If you wrote `LanS :: !(Fin i) -> LanS (S i)` then it would satisfy the conditions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 16 Aug '16

16 Aug '16

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5927: A type-level "implies" constraint on Constraints
by GHC 15 Aug '16

15 Aug '16

#5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: I //do// have a pratical use-case for this feature: I think it would help solve part of the story for being able to derive `Generic` instances for GADTs (see Trac issues #8560 and #10514). In particular, I think `ImplicationConstraints` would allow be to be polymorphic over any existentially quanitified constraint in a GADT. In particular, there are GADTs like this: {{{#!hs class GShow a where gshow :: a -> String data T a where MkT :: GShow a => a -> T a }}} GHC generics currently lacks a facility for expressing the existential `GShow` constraint. I think we could add something like this: {{{#!hs data EC c f a where MkEC :: c => f a -> EC c f a }}} Then we could derive a `Generic` instance for `T` like so: {{{#!hs instance Generic (T a) where type Rep (T a) = D1 ('MetaData "T" "Ghci2" "interactive" 'False) (C1 ('MetaCons "MkT" 'PrefixI 'False) (EC (GShow a) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 a)))) from (MkT x) = M1 (M1 (MkEC (M1 (K1 x)))) to (M1 (M1 (MkEC (M1 (K1 x))))) = MkT x }}} So far, so good. Now I want to be able to define a generic `GShow` instance for `T` (where `GShow` comes from the [http://hackage.haskell.org/package/generic-deriving-1.10.7/docs/Generics- Deriving-Show.html generic-deriving] library). We already have cases for all generic datatypes except `EC`. This is what I want to be able to write: {{{#!hs class GShow' f where gshow' :: f a -> String instance (c => GShow' f) => GShow' (EC c f) where gshow' (MkEC x) = gshow' x }}} But for that, I need `ImplicationConstraints`. If I want to generalize this to `Generic1` instances, I'd probably need `QuantifiedConstraints` too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5927#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2893: Implement "Quantified contexts" proposal
by GHC 15 Aug '16

15 Aug '16

#2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2893#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1?
by GHC 15 Aug '16

15 Aug '16

#7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1? -------------------------------------+------------------------------------- Reporter: spl | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by spl): * cc: leather@… (removed) * cc: spl (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7492#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11794: Switch to LLVM 3.8
by GHC 15 Aug '16

15 Aug '16

#11794: Switch to LLVM 3.8 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (LLVM) | 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: -------------------------------------+------------------------------------- LLVM 8.0 has been released and I (@erikd) already have patches for make GHC compile with LLVM 3.8. This ticket is just a placeholder so that when GHCHQ want to move to the new version, they just have to let me know in this ticket and I'll prepare the patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11794> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1?
by GHC 15 Aug '16

15 Aug '16

#7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1? -------------------------------------+------------------------------------- Reporter: spl | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This `Functor` issue might become less important in the future if we switch over to using a coercion-based approach to deriving `Generic1`. See https://ghc.haskell.org/trac/ghc/ticket/8516#comment:5 for more info. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7492#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper
by GHC 14 Aug '16

14 Aug '16

#5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Inlining 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: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5928#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Fw: exciting news
by matthew 13 Aug '16

13 Aug '16

Hi! I've just read that news, and I'm so excited, you've got to see it too <http://zispukiqui.pitsch.us/lndmd> matthew

1 0

[GHC] #12486: Investigate removing libGCC symbols from RtsSymbols.c
by GHC 13 Aug '16

13 Aug '16

#12486: Investigate removing libGCC symbols from RtsSymbols.c -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11981 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The RTS is currently re-exporting symbols from the C compiler runtime in `RtsSymbols.c`. How this works is that the Runtime linker is declaring that it can provide these symbols because it's been linked against the C compiler library itself. In essence it's providing pointers to it's own symbol table. This Is fine but has two downsides: 1) We have to keep adding symbols to export anytime the underlying C compiler changes things or someone needs a new symbol from the library. 2) User code that is linking explicitly against these libraries will probably generate a duplicate symbols error if it needs a symbol we have not yet exported but is in the same object file or dependency of a symbol we have exported. One solution would be to add `libgcc_s` to the dependencies of `ghc-prim` which is the package that seems to require them. This has two issues with it: `GCC_S` doesn't exist for llvm, so we need to somehow know which compiler we're compiling for. Secondly on Windows `GCC_S` is an import library with a non-standard name. (.a instead of .dll.a) and we currently cannot recognize it as such. We'd try to load it as a normal archive and end up trying to execute ascii as code. This task is to find a way to remove the need to export these symbols yet still work with both GCC and LLVM. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12486> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0