- ghc-tickets - Haskell.org

Re: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints
by GHC 08 Mar '17

08 Mar '17

#2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.8.2 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by nfrisby): Your `min` discussion was helpful to me, but I think it's mostly unrelated, in retrospect; the `Ord a` dictionary -- again ignoring overlapping/incoherent instances -- could only ever "overlap" with a parametric instance of `Ord`, since `a` is skolem. #9701, on the other hand, seems to demonstrate exactly what you were getting at (#12791 too?). Replying to [comment:14 goldfire]: > I initially put this ticket into my internal notes as "Difficulty: Rocket Science", but I've changed my mind. I think this is actually straightforward to implement. > > GHC already has implication constraints, except that they're effectively all Wanteds. So, all we would need are to be able to make Given implication constraints. But, these should be rather straightforward, because we can view top-level instances as Given implication constraints. We can just adapt the current look-in-Givens algorithm to do some matching, just like the instance-selection algorithm does. When we find an implication-constraint Given that matches a Wanted, we use it to solve the Wanted and then emit new Wanteds for the antecedents of the Given implication. > > I was initially concerned about overlap here -- what if an implication Given's RHS overlaps with a global instance? -- but this was a red herring. Givens have always potentially overlapped with global instances, and very few people are bothered. For example: > > {{{ > min :: Ord a => a -> a -> a > }}} > > If we call `min` at type `Int`, the `Ord` constraint is potentially ambiguous: do we mean the dictionary supplied or the global `Ord Int` dictionary? Of course, we mean the local one, and we don't require `-XIncoherentInstances` to do so. So, worrying about overlap in the context of implication Givens is a red herring. We have a clear rule: local constraints always shadow global ones. That's nice, simple, and unsurprising. > > This also doesn't change the "GHC never backtracks" principle. If a local implication-constraint's RHS matches, it is used, just like if GHC finds a global implication constraint (read, global constrained instance). > > To implement this, GHC would also need to be able to produce the witness for an implication constraint, but this is just like inferring the lambdas for a higher-rank type. I don't see any challenge here. > > Of course, a niggling feeling tells me that this ''has'' to be harder than I'm seeing it. But, really, all I see standing in the way is a bit of plumbing. > > Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2256#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints
by GHC 08 Mar '17

08 Mar '17

#2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.8.2 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by nfrisby): Does the following claim hold water and/or illuminate anything? The implication constraint on `implic` can either be simplified (eg `C a` immediately refines `a` and/or has `D a` as a superclass) or it is only satisfiable by a parametric instance of `D`. Suppose that overlapping and incoherent instances are not allowed. Then any non-parametric instance of `D` (eg your `D Int`) would immediately render that implication constraint unsatisfiable. So the concern is just yet another due solely to overlapping/incoherent instances? Replying to [comment:16 goldfire]: > * Inference: We don't. Just like we don't infer higher-rank types (which, of course, are the same as implication constraints). If a user wants this feature, they have to ask for it. > > * Completeness: This is thornier. Here is how I see a problem arising: > > {{{ > class C a > class D a > instance D Int > > needsD :: D a => a -> () > implic :: (forall a. C a => D a) -> () > implic = needsD (5 :: Int) > }}} > > When typechecking `implic`, the local universal dictionary for `D a` will be used to provide a dictionary to `needsD`. This will then generate an unsatisfiable wanted `C Int`. But, of course, we could have just used the global instance `D Int` instead. > > An issue such as this one can't arise today (even with local dictionaries shadowing global ones) because local dictionaries never give rise to new wanteds. If you have a local dictionary, it's good to use. > > Given/Given interactions would be the same. If one implication-Given can be used in an interaction, it would be, giving rise to its antecedent Wanted constraints. > > This does get me a little worried about nondeterminism. But, I conjecture that if this interaction can give rise to nondeterminism, then it would be possible to exhibit the nondeterminism today, using overlapping instances. > > So, it all comes down to specifying completeness against what spec, and I'm saying that we could be complete against a spec where every local constraint shadows every overlapped global one. That is, when `(forall a. C a => D a)` is in scope, `instance D Int` is not. Will this be easy enough to use to make it practicable? There will be some surprises around it, but I think it's all quite easy to digest with a little guidance. (Certainly easier to understand than closed type families!) > > * Impredicativity: This, to me, is just like the story in kind `*`. `c` should be forbidden from unifying with an implication constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2256#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c
by GHC 08 Mar '17

08 Mar '17

#13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c ------------------------------+------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+------------------------------- When you press and hold Ctrl-c, after a few seconds, sometimes > 60 sec, GHCi crash and we can read a message on the screen (of the console) who says: {{{ ghc.exe : failed to create OS thread }}} On the task manager we can read: {{{ ghc memory : 36920K }}} initially, then the memory grows about {{{ ghc memory : 43480K }}} and stay until the crash. I repeated it several times. With Linux if you repeat this, GHCi do not crash. Idem with only the Windows console. Hope this help! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] Trac email verification for user: sheyll
by GHC 08 Mar '17

08 Mar '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=JSlhZPyV> Username: sheyll Verification Token: JSlhZPyV -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing
by GHC 08 Mar '17

08 Mar '17

#10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: base/tests/exceptionsrun001 | Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following program, extracted from the test exceptionsrun001, should exit with exitcode 100. Instead, when compiled with `-O1`, it never gets past the ioTest and somehow manages to exit with exitcode 0. {{{ {-# LANGUAGE ScopedTypeVariables #-} module Main where import Control.Exception import System.IO.Error import System.Exit main = do ioTest exitWith (ExitFailure 100) ioTest :: IO () ioTest = (catch (ioError (userError "wibble")) (\(e::IOException) -> return ()) }}} I think this will require a git bisect: * last known good commit: 34bb4605d4ec5b131df57ca4c91d6840b7539194 * first known bad commit: f83aab95f59ae9b29f22fc7924e050512229cb9c. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10712> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #13212: Support abs as a primitive operation on floating point numbers.
by GHC 08 Mar '17

08 Mar '17

#13212: Support abs as a primitive operation on floating point numbers. -------------------------------------+------------------------------------- Reporter: dominic | 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: -------------------------------------+------------------------------------- Haskell differs from C and FORTRAN on the manner in which it computes the absolute value of floating point numbers. Both FORTRAN and C support a `fabs` primitive function that is compiled directly to the underlying `fabs` machine instruction on either AMD64 or Intel x86 processors (with a small amount of stack manipulation). Haskell, however, does not support `abs` as a primitive operation on floating point numbers. Instead, Haskell desugars `abs` to the following: abs x | x == 0 = 0 -- handles (-0.0) | x > 0 = x | otherwise = negateFloat x Rather than calling the utilizing the `fabs` mnemonic or twiddling the sign bit, both of which can be executed in a single instruction, this implementation results in ~15 machine instructions and requires ~4-5 times the number of clock cycles to execute. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13212> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 08 Mar '17

08 Mar '17

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ThreeFx): Even with `fno-state-hack` this program succeeds under GHC version 8.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13389: Strange behaviours of memory with GHCi under Windows and Linux
by GHC 08 Mar '17

08 Mar '17

#13389: Strange behaviours of memory with GHCi under Windows and Linux -------------------------------------+------------------------------------- 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: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With Windows : Initially the memory in the computer is at 34% use. I open 30 consoles Windows of GHCi. The memory grows until 70% use. I decided to crash a console with this function {{{ f x = x**6 + f x }}} Suddenly the % of memory fall to around 35%. Then I decided to open 30 others consoles Windows GHCi. The memory grows to 83% use. I crashed a console with the same function and the memory fall to 41%. Then I looked at the task manager and I see 29 process of GHC had a memory between 444K and 356K, and 30 process of GHC had a memory between 34704K and 20160K. I decided to made a crash dump file with a process of GHC with 440K of memory. When the crash dump file begin, the memory of the process grows to 80376K and stay until the dump file stop to write. With Linux : I repeted the same behaviour. Initially the memry had 29% use. After the crash of GHCi the memory fall to 8% use. I looked at the task manager and somes process of GHC had 40Kio and others 8192o. I decided to stop (not to kill) a process of GHC and then to continue it. After that the memory of the process grows to 75Mio.\\ Hope this help! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13389> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11006: Warning: Glomming in Main
by GHC 07 Mar '17

07 Mar '17

#11006: Warning: Glomming in Main -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- The Travis build bot is reporting a test failure with debugging on, relating to glomming: {{{ Actual stderr output differs from expected: --- /dev/null 2015-01-28 16:31:58.000000000 +0000 +++ ./lib/integer/integerConstantFolding.run.stderr.normalised 2015-10-22 20:31:03.287376925 +0000 @@ -0,0 +1,2 @@ +WARNING: file compiler/simplCore/OccurAnal.hs, line 66 + Glomming in Main: [s3k0 :->, s3kc :->, s3kq :->, s3kr :->] \ No newline at end of file *** unexpected failure for integerConstantFolding(normal) }}} Full log https://s3.amazonaws.com/archive.travis- ci.org/jobs/86899099/log.txt -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11006> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13130: atomicModifyMutVar# has incorrect type
by GHC 07 Mar '17

07 Mar '17

#13130: atomicModifyMutVar# has incorrect type -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- this ticket specifically, currently we only expose in ghc-prim {{{ atomicModifyMutVar# :: MutVar# s a -> (a -> b) -> State# s -> (# State# s,c #) }}} is the type more like the following? {{{ atomicModifyMutVar# :: MutVar# s a -> (a -> (#a,b #)) -> State# s -> (# State# s,b #) }}} looking at GHC.IOREF {{{ atomicModifyIORef :: IORef a -> (a -> (a,b)) -> IO b atomicModifyIORef (IORef (STRef r#)) f = IO $ \s -> atomicModifyMutVar# r# f s }}} it seems that either way, something screwy is afoot i'm not sure where the spurious c type variable comes from -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3