- ghc-tickets - Haskell.org

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 18 Aug '16

18 Aug '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by niteria): It's been a while since my last commit, so I will give a quick status update. Determinism is coming to 8.0.2, Ben Gamari kindly merged all the patches I sent him. Thanks Ben! That's a subset of the patches on this ticket, but a subset that was sufficient during my testing on GHC and Stackage to make the results deterministic (interface file determinism). That said phab:D2288, being a TH change couldn't make it into 8.0.2. Fortunately the packages that tripped up on it have been fixed: https://github.com/aelve/microlens/issues/83, https://github.com/ekmett/lens/issues/669. Props to the maintainers for the lightning fast fix! If you're in a position to test 8.0.2 for determinism before it comes out, any reports would be appreciated. No refunds though! Is this ticket ready to be closed? Not yet, it's still possible to accidentally reintroduce non-determinism in GHC. `Ord Unique` is removed, but `UniqFM` doesn't use it and just gets the underlying integer. More work needs to be done to remove non- deterministic operations on `UniqFM`. I intend to do this work, but currently I shifted my focus to migrating to the soon-to-be GHC 8.0.2 within my company. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 17 Aug '16

17 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've lost context on this. The trac ticket is very long, and I'm no longer sure * What, exactly, is the problem we are trying to solve? * What's the overview of the proposed solution? * How the solution works in detail I wonder whether you might write a wiki page on Literal Strings, to describe how literal strings are handled, at least in your proposal? Are there any tests that check that the problem is indeed solved? I notice that the Phab patch changes `.gitmodules` to point to your repos, which presumably can't be right for a commit to GHC master. Sorry to be dense. Thanks. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 17 Aug '16

17 Aug '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:59> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11385: Unify named wildcards in different type applications
by GHC 17 Aug '16

17 Aug '16

#11385: Unify named wildcards in different type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple NamedWildCards TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ([https://www.reddit.com/r/haskell/comments/4030lv/unifying_distinct_type_var… motivating post]) I would like to use type application to specialize {{{#!hs Sub :: forall (a :: Constraint) (b :: Constraint). (a => Dict b) -> a :- b Sub @(Ord _a) @(Eq _a) :: forall {a}. (Ord a => Dict (Eq a)) -> Ord a :- Eq a }}} and {{{#!hs map :: forall a b. (a -> b) -> [a] -> [b] map @_a @_a :: forall {a}. (a -> a) -> [a] -> [a] }}} Is there a fundamental reason why named wildcards are not allowed to unify between type applications within the same expression? [https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #named-wildcards Documentation]: > These are called named wildcards. All occurrences of the same named wildcard within one type signature will unify to the same type. I don't know if this is intended. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11385> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9498: GHC links against unversioned .so files
by GHC 16 Aug '16

16 Aug '16

#9498: GHC links against unversioned .so files ------------------------------------+-------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Keywords: Debian | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+-------------------------------- Greetings, GHC tries to load unversioned dynamic libraries instead of versioned (i.e. libfoo.so instead of libfoo.so.1.2.3). This is a problem, since Distributions like Debian (I don't know about other distributions) don't include unversioned .SOs in their runtime packages and the unversioned are only available in the -dev packages as a symlink to the verioned ones. This means FFI libraries depend on the -dev packages, even though they don't really need them. It would be nice if GHC would try to load the versioned libraries as well. Regards Sven -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #12384: Type family not reduced, again
by GHC 16 Aug '16

16 Aug '16

#12384: Type family not reduced, again -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This one looks similar to #12381, but unfortunately, it does not seem to be fixed in HEAD: {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies, FlexibleInstances #-} import GHC.Types type family F (a :: Type) :: Type class C a where type D (a :: Type) :: F a instance (F a ~ Bool) => C a where type D a = True }}} This yields (in 8.0.1 and 8.1.20160709): {{{ Constraint.hs:11:14: error: • Expected kind ‘F a’, but ‘'True’ has kind ‘Bool’ • In the type ‘True’ In the type instance declaration for ‘D’ In the instance declaration for ‘C a’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12384> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

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 oerjan): `LanO` might, however, be a candidate for being zero width when in a strict field, which could help ''other'' types satisfy the newtype condition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:34> 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: | -------------------------------------+------------------------------------- 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