August 2017 - ghc-tickets

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

18 Aug '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: strings 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 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > My understanding of this problem is that we want a way to tell ghc how to compile literals. That's the bit under "Haskell" in comment:86. But we still need to compile them into something. But what? That's the bit under "Core" in comment:86. Once we have the Core bit settled we can return to the Haskell bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:88> 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 18 Aug '17

18 Aug '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: strings 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 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): > I'm struggling to grok this ticket, especially: what is the problem we are trying to solve?. I'm also concerned about making things too complicated. > The ability to put a block of binary data in the program code, without heavy encoding. My understanding of this problem is that we want a way to tell ghc ''how'' to compile literals. The ''compiler's'' interpretation of `"..."`, `"..."#`, `[...]` are currently fixed , and we have to do runtime conversion in order to get the interpretation ''we want''. The difference between compiler's and user's interpretation may be address vs heap object, or utf8 vs modified utf8 vs utf16, these difference will decide how codegen emit literal code. So we have to find a way to tell compiler what kind of interpretation we want, it can be via syntax, e.g. we create different syntax for different interpretation. Or we can use some type magic, e.g. the one i suggest. I believe each solution has its own pro and cons. In short words, i believe this is a problem `OverloadedString/OverloadedList` are intended to solve, but solved it wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:87> 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 18 Aug '17

18 Aug '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: strings 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 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm struggling to grok this ticket, especially: '''what is the problem we are trying to solve?'''. I'm also concerned about making things too complicated. ''jscholl in comment:74 sounds right on target to me''. Here's my thinking, written out. Let's see if we agree at least about the "Goals" and "Core" part. == Goals == I believe that one goal is * '''The ability to put a block of binary data in the program code, without heavy encoding.''' Is that a goal? Can we focus solely on that for a while? == Core == To meet that goal, in Core, we need * A primitive data type `B#` whose values are simply blobs of binary data. * Some operations over this type; e.g. `lenB :: B# -> Int`, or `unpackString :: B# -> [Char]` or whatever. * Literal values (in Core) for `B#` values. `B#` plays the role of the `(# Int#, Addr# #)` representation mentioned above (comment:38 ff), but without being so concrete. I'm only using "`B#`" as a placeholder; we need a proper name for it! So what is it, precisely? * `B#` could be a completely new primitive type. * Or `B#` could be `ByteArray#`. That would have the major advantage of not adding a new type, and for sure we'd need to be able to turn it into a `ByteArray#`. So I like that, and it's what jscholl suggests in comment:74. * But `B#` can't be `Addr#` (which is a memory address)! Also look at #11312, which is highly relevant because it has the same conclusion. In #11312, I call this new type `String#`, but that's too character-oriented. I think we should focus on binary data. But adopting `B#` would fix the ghastly problems in #11312. == Haskell == If we had this new primitive type, we'd soon want literals for it in Haskell source code. * I suppose we could have a new literal syntax (about whose details I am intensely relaxed). After all, the literals of a language should be expressible I suppose. * But we could say you could only get it via a TH quasiquote e.g. `[bytes| fec923ac |]`? Is that so terrible? Note that everything in comment:84 belongs in this section. By the time we get to Core all this typeclass stuff has gone away. == Other goals == I don't have clarity on how `bytestring` would want to convert a `ByteArray#` to a `ByteString`. That ought to be a constant time operation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:86> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3474: Add a strict variant of iterate to Data.List
by GHC 18 Aug '17

18 Aug '17

#3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3870 Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > I suggest adding a strict variant of the iterate function to the > Data.List module, as others seem to have had a need for it too. It is > useful when you want to repeatedly apply a function a large number of > times and get the final result. Using the standard iterate function in > this way results in the whole list being held in memory, as exemplified > in the following GHCi session (code compiled with -O2 behaves similarly): > > > let f = (+1) in iterate f 0 !! 10000000 > *** Exception: stack overflow > > Using a strict variant of iterate seems to be sufficient for this code to > run in O(1) memory: > > > let iterate' f x = x `seq` x : iterate' f (f x) > > let f = (+1) in iterate' f 0 !! 10000000 > 10000000 > > I have no idea if this is something that could/should be detected by the > strictness analyzer; that would obviously be preferable if it is indeed > possible. New description: I suggest adding a strict variant of the iterate function to the Data.List module, as others seem to have had a need for it too. It is useful when you want to repeatedly apply a function a large number of times and get the final result. Using the standard iterate function in this way results in the whole list being held in memory, as exemplified in the following GHCi session (code compiled with -O2 behaves similarly): {{{ > let f = (+1) in iterate f 0 !! 10000000 *** Exception: stack overflow }}} Using a strict variant of iterate seems to be sufficient for this code to run in O(1) memory: {{{ > let iterate' f x = x `seq` x : iterate' f (f x) > let f = (+1) in iterate' f 0 !! 10000000 10000000 }}} I have no idea if this is something that could/should be detected by the strictness analyzer; that would obviously be preferable if it is indeed possible. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3474#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3474: Add a strict variant of iterate to Data.List
by GHC 18 Aug '17

18 Aug '17

#3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3870 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3474#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3474: Add a strict variant of iterate to Data.List
by GHC 18 Aug '17

18 Aug '17

#3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: patch Priority: normal | Milestone: 8.2.2 Component: libraries/base | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3870 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3870 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3474#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14085: powModInteger sometimes ignores sign of argument
by GHC 18 Aug '17

18 Aug '17

#14085: powModInteger sometimes ignores sign of argument -------------------------------------+------------------------------------- Reporter: ocheron | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.2.1 Libraries | Keywords: integer-gmp | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Function `intToSBigNat#` returns a `PosBN` result when input is < -1, but it should be `NegBN` instead. As a consequence functions like `powModInteger` give incorrect result for small negative numbers: {{{ $ ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help > :m GHC.Integer.GMP.Internals > powModInteger (-2) 3 123 8 > (-2)^3 `mod` 123 115 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14085> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism
by GHC 18 Aug '17

18 Aug '17

#13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code fails to compile, but probably should: {{{ {-# LANGUAGE RankNTypes, TypeInType #-} import Data.Kind data Foo :: forall k . (* -> *) -> k -> * -- Decl 1 class C (a :: forall k . k -> *) instance C (Foo a) -- error on this line }}} with the error {{{ • Expected kind ‘forall k. k -> *’, but ‘Foo a’ has kind ‘k0 -> *’ • In the first argument of ‘C’, namely ‘Foo a’ In the instance declaration for ‘C (Foo a)’ }}} Similarly, the following declarations of `Foo` also cause a similar error at the instance declaration: Decl 2: `data Foo :: (* -> *) -> k -> *` Decl 3: `data Foo (a :: * -> *) (b :: k)` However, if I move the `forall` to a point ''after'' the first type parameter (which is where the instance is partially applied) thusly: Decl 4: `data Foo :: (* -> *) -> forall k . k -> *` then GHC happily accepts the instance of `C`. From my (admittedly negligible) knowledge of type theory, the signatures for Decls 1 and 4 (and 2) are identical, since the `forall` can be floated to the front of Decl 4. GHC should accept any of the four versions of `Foo`, since they are all equivalent. As a side note, I was surprised to discover that the syntax for Decl 4 is even allowed. What is the point of allowing a "global"/rank-1 forall anywhere but at the left edge of the signature (other than as a convenient workaround for this bug)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13399> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14106: Out of scope errors appear after type errors caused by them
by GHC 18 Aug '17

18 Aug '17

#14106: Out of scope errors appear after type errors caused by them -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Example: import Control.Lens (_Just, (&)) main = Just 5 & _Just .~ 100 & print .~ is out of scope, the error output: ghc-error.hs:2:17-21: error: … • Couldn't match type ‘Maybe’ with ‘p0 a0’ Expected type: Maybe (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) Actual type: p0 a0 (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) • In the second argument of ‘(&)’, namely ‘_Just’ In the first argument of ‘(.~)’, namely ‘Just 5 & _Just’ In the expression: (.~) Just 5 & _Just 100 & print ghc-error.hs:2:23-24: error: … • Variable not in scope: (.~) :: p0 (Maybe a0) (f0 (Maybe b0)) -> IO () -> t • Perhaps you meant ‘.’ (imported from Prelude) Perhaps you want to add ‘.~’ to the import list in the import of ‘Control.Lens’ (/home/eyal/devel/test/ghc-error.hs:1:1-32). Compilation failed. In larger examples, the out of scope error can be buried deep down. In the case of operators - the fixity is unknown so it can even cause the parse to go wrong - and very weird type errors to result from that. Out of scope errors should be put BEFORE any type errors that might be caused by them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows
by GHC 18 Aug '17

18 Aug '17

#12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Relevant code: {{{ -- | @setEnv name value@ sets the specified environment variable to @value@. -- -- On Windows setting an environment variable to the /empty string/ removes -- that environment variable from the environment. For the sake of -- compatibility we adopt that behavior. In particular -- -- @ -- setEnv name \"\" -- @ -- -- has the same effect as -- -- @ -- `unsetEnv` name -- @ }}} This sounds nice and authoritative... and it's also not true. https://msdn.microsoft.com/en- us/library/windows/desktop/ms686206(v=vs.85).aspx states that only if the pointer is NULL (as opposed to an empty string) is the environment variable deleted. https://github.com/golang/go/issues/5610 corroborates So `setEnv` has been given bogus semantics that don't make sense because empty environment variables ARE supported on Windows. My suggestion is to just fix this so that setEnv takes empty environment variables. But this would be a BC breaking change. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13