- ghc-tickets - Haskell.org

[GHC] #13537: Adding underscore (m :: _) to pattern variable makes it fail
by GHC 07 Apr '17

07 Apr '17

#13537: Adding underscore (m :: _) to pattern variable makes it fail -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- This works fine {{{#!hs {-# Language RankNTypes, TypeOperators, KindSignatures, GADTs, ScopedTypeVariables, PolyKinds #-} import Data.Kind data CodTy :: (k -> Type) -> Type where CodTy :: { runCodTy :: (forall r. (f ty -> r) -> r) } -> CodTy f type f ~> g = forall xx. f xx -> g xx fmap' :: (f ~> f') -> (CodTy f -> CodTy f') fmap' f (CodTy m) = CodTy $ \ c -> m (c . f) }}} but adding {{{#!hs fmap' f (CodTy (m :: _)) = CodTy $ \ c -> m (c . f) }}} makes it fail (also fails without `PolyKinds`) {{{ $ ghci -ignore-dot-ghci tNT2.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tNT2.hs, interpreted ) tNT2.hs:11:22: error: • Found type wildcard ‘_’ standing for ‘(f ty -> r0) -> r0’ Where: ‘r0’ is an ambiguous type variable ‘f’ is a rigid type variable bound by the type signature for: fmap' :: forall k (f :: k -> *) (f' :: k -> *). f ~> f' -> CodTy f -> CodTy f' at tNT2.hs:10:10 ‘ty’ is a rigid type variable bound by a pattern with constructor: CodTy :: forall k (f :: k -> *) (ty :: k). (forall r. (f ty -> r) -> r) -> CodTy f, in an equation for ‘fmap'’ at tNT2.hs:11:10 ‘k’ is a rigid type variable bound by the type signature for: fmap' :: forall k (f :: k -> *) (f' :: k -> *). f ~> f' -> CodTy f -> CodTy f' at tNT2.hs:10:10 To use the inferred type, enable PartialTypeSignatures • In a pattern type signature: _ In the pattern: m :: _ In the pattern: CodTy (m :: _) • Relevant bindings include f :: f ~> f' (bound at tNT2.hs:11:7) fmap' :: f ~> f' -> CodTy f -> CodTy f' (bound at tNT2.hs:11:1) tNT2.hs:11:46: error: • Couldn't match type ‘r0’ with ‘r’ because type variable ‘r’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: (f' ty -> r) -> r at tNT2.hs:11:28-51 Expected type: f ty -> r0 Actual type: f ty -> r • In the first argument of ‘m’, namely ‘(c . f)’ In the expression: m (c . f) In the second argument of ‘($)’, namely ‘\ c -> m (c . f)’ • Relevant bindings include c :: f' ty -> r (bound at tNT2.hs:11:38) m :: (f ty -> r0) -> r0 (bound at tNT2.hs:11:17) Failed, modules loaded: none. Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13537> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

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

07 Apr '17

#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 winter): > This would essentially amount to making `ByteArray#` a sum internally. You would simply add a closure type which would carry a pointer to the payload instead of the VLA carried by `StgArrBytes` currently. I'm not an expert on this, so maybe this sounds ridiculous: If we add a new closure type for `ByteArray#`, could it be used in runtime also? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:65> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13538: Weird kind inference problems with closed type families
by GHC 07 Apr '17

07 Apr '17

#13538: Weird kind inference problems with closed type families -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | 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: -------------------------------------+------------------------------------- Consider a problem of injective cons on a type-level list [https://ghc.haskell.org/trac/ghc/ticket/12114] I made a small workaround by adding an intermediate data type `List1 k`. Here is my code: {{{#!hs {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeFamilies, TypeFamilyDependencies #-} {-# LANGUAGE KindSignatures, DataKinds, PolyKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeApplications #-} module TFTest where import GHC.TypeLits import Data.Proxy -- | Synonym for a type-level snoc (injective!) type (ns :: [k]) +: (n :: k) = GetList1 (SinkFirst (n ': ns)) infixl 5 +: -- | A weird data type used to make `(+:)` operation injective. -- `List k [k]` must have at least two elements. data List1 k = L1Single k | L1Head k [k] -- | Sink first element of a list to the end of the list type family SinkFirst (xs :: [k]) = (ys :: List1 k) | ys -> xs where SinkFirst '[y] = 'L1Single y -- SinkFirst (y ': x ': xs :: [Nat]) -- = ('L1Head x (GetList1Nat (SinkFirst (y ': xs))) :: List1 Nat) SinkFirst (y ': x ': xs :: [k]) = ('L1Head x (GetList1 (SinkFirst (y ': xs))) :: List1 k) type family GetList1 (ts :: List1 k) = (rs :: [k]) | rs -> ts where GetList1 ('L1Single x) = '[x] GetList1 ('L1Head y (x ':xs)) = y ': x ': xs type family GetList1Nat (ts :: List1 Nat) = (rs :: [Nat]) | rs -> ts where GetList1Nat ('L1Single x) = '[x] GetList1Nat ('L1Head y (x ': xs)) = y ': x ': xs type family (++) (as :: [k]) (bs :: [k]) :: [k] where '[] ++ bs = bs (a ': as) ++ bs = a ': (as ++ bs) ff :: Proxy k -> Proxy (as +: k) -> Proxy (k ': bs) -> Proxy (as ++ bs) ff _ _ _ = Proxy yy :: Proxy '[3,7,2] yy = ff (Proxy @5) (Proxy @'[3,7,5]) (Proxy @'[5,2]) }}} This gives me the following error: {{{ ~/TFTest.hs: 47, 21 • Couldn't match kind ‘k’ with ‘Nat’ When matching the kind of ‘7 : xs’ Expected type: Proxy ((3 : (7 : xs)) +: 5) Actual type: Proxy '[3, 7, 5] • In the second argument of ‘ff’, namely ‘(Proxy @'[3, 7, 5])’ In the expression: ff (Proxy @5) (Proxy @'[3, 7, 5]) (Proxy @'[5, 2]) In an equation for ‘yy’: yy = ff (Proxy @5) (Proxy @'[3, 7, 5]) (Proxy @'[5, 2]) }}} However, if I uncomment lines `26-27`, the code works perfectly fine! This behaviour feels like a bug in type checker, though I am not sure. If it is not, please, explain me what happens here? :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13538> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

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

07 Apr '17

#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 bgamari): > But i fail to understand how can we provide `unsafeMkByteArray#` in an obvious way. This would essentially amount to making `ByteArray#` a sum internally. You would simply add a closure type which would carry a pointer to the payload instead of the VLA carried by `StgArrBytes` currently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:64> 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 07 Apr '17

07 Apr '17

#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 winter): > Fair enough, but why not just poke a hole in the `ByteArray#` abstraction in that case? Namely, provide a `unsafeMkByteArray# :: Addr# -> Int -> ByteArray#`. > Although, thinking about this for a tad longer it's not necessarily clear that this is a direction which we'd want to go. Afterall, it would require the introduction of another closure type since the current representation requires that the bytes directly follow the closure header. I suspect this would introduce quite a bit of complexity in the RTS. Yes, that is a more expensive design IMO. I read about the notes on unpointed heap object(maybe somewhere in `infoTable.h`), it says that they shouldn't be entered. But i fail to understand how can we provide `unsafeMkByteArray#` in an obvious way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:63> 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 07 Apr '17

07 Apr '17

#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 bgamari): > Fair enough, but why not just poke a hole in the `ByteArray#` abstraction in that case? Namely, provide a `unsafeMkByteArray# :: Addr# -> Int -> ByteArray#`. Although, thinking about this for a tad longer it's not necessarily clear that this is a direction which we'd want to go. Afterall, it would require the introduction of another closure type since the current representation requires that the bytes directly follow the closure header. I suspect this would introduce quite a bit of complexity in the RTS. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:62> 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 07 Apr '17

07 Apr '17

#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 bgamari): Replying to [comment:60 winter]: > > What is stopping these libraries from providing this mechanism currently using Addr# and primitive strings directly? > > The problem is that there's no way to cast `Addr#` into `ByteArray#` without copy, while unboxed vector(not storable) and text both want `ByteArray#`. > Fair enough, but why not just poke a hole in the `ByteArray#` abstraction in that case? Namely, provide a `unsafeMkByteArray# :: Addr# -> Int -> ByteArray#`. > > In general primitive strings are, as the name would suggest, primitive. I'm not sure forcing a heap object representation here is necessary nor prudent. > > I disagree. If we give string literal a proper compact representation, not only we can save unnecessary copying during runtime, we can save code size in other ways. > > Consider if string literal now are `ByteArray#`s, we can use rules to simplify a UTF8 text type like `forall a. fromString (GHC.unpackCString# a) = UTF8 a`, that means we can directly use constructor here instead of several calls. The same applys for unbox vectors using unboxed string literal and hexdecimal notation. I agree that these are all great simplifications, but I don't see why changing the representation of primitive strings is necessary to get there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:61> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13534: ghc-8.2.0.20170404/testsuite/timeout failed to build
by GHC 07 Apr '17

07 Apr '17

#13534: ghc-8.2.0.20170404/testsuite/timeout failed to build --------------------------------------+--------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: timeout | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- {{{ Looks like you don't have timeout, building it first... make -C ../timeout all make[2]: Entering directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' rm -f -f TimeMe.o TimeMe.hi TimeMe TimeMe.exe python3 calibrate '' > calibrate.out Traceback (most recent call last): File "calibrate", line 20, in <module> compiler_name, 'TimeMe.hs', '-o', 'TimeMe', '-O2') File "/usr/lib64/python3.6/os.py", line 920, in spawnl return spawnv(mode, file, args) File "/usr/lib64/python3.6/os.py", line 871, in spawnv return _spawnvef(mode, file, args, None, execv) File "/usr/lib64/python3.6/os.py", line 838, in _spawnvef raise ValueError('argv first element cannot be empty') ValueError: argv first element cannot be empty make[2]: Leaving directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' make[2]: *** [Makefile:54: calibrate.out] Error 1 make[1]: Leaving directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/tests' make[1]: *** [../mk/test.mk:293: ../timeout/install-inplace/bin/timeout] Error 2 make: *** [Makefile:217: test] Error 2 }}} Full buildlog at https://copr- be.cloud.fedoraproject.org/results/petersen/ghc-8.2.1/fedora-26-x86_64/0053… (for a couple of weeks) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

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

07 Apr '17

#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 winter): > What is stopping these libraries from providing this mechanism currently using Addr# and primitive strings directly? The problem is that there's no way to cast `Addr#` into `ByteArray#` without copy, while unboxed vector(not storable) and text both want `ByteArray#`. > In general primitive strings are, as the name would suggest, primitive. I'm not sure forcing a heap object representation here is necessary nor prudent. I disagree. If we give string literal a proper compact representation, not only we cab save unnecessary copying during runtime, we can save code size in other ways. Consider if string literal now are `ByteArray#`s, we can use rules to simplify a UTF8 text type like `forall a. fromString (GHC.unpackCString# a) = UTF8 a`, that means we can directly use constructor here instead of several calls. The same applys for unbox vectors using unboxed string literal and hexdecimal notation, which we have to use `fromList` and a real list now(which carrys a much larger overhead). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:60> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4862: Enable usage of gold linker with GHC
by GHC 07 Apr '17

07 Apr '17

#4862: Enable usage of gold linker with GHC -------------------------------------+------------------------------------- Reporter: ajd | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 7.4.3 Component: Compiler | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have opened #13541, which describes a proposal for making it easier to use `gold`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4862#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0