- ghc-tickets - Haskell.org

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 21 Sep '15

21 Sep '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192 -------------------------------------+------------------------------------- Changes (by meteficha): * cc: felipe.lessa@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 21 Sep '15

21 Sep '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192 -------------------------------------+------------------------------------- Comment (by meteficha): Assuming that the main source of non-deterministic Uniques is the non- deterministic, lazy I/O, how about making a different Unique "namespace" for each file? Conceptually, it would mean having: {{{#!hs data Unique = MkUnique {-# UNPACK #-} !Int (Maybe ModuleName) }}} There could still be problems if each file was processed in a non- deterministic way, but now files could be processed in any order without changing the Uniques. This is of course an extremely naive suggestion, I'm sharing it with the hope that it may spark some better idea in someone else's mind :). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:119> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 21 Sep '15

21 Sep '15

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by zardoz): * cc: zardoz (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10903: Add an option to infer CallStack implicit parameters
by GHC 21 Sep '15

21 Sep '15

#10903: Add an option to infer CallStack implicit parameters -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | 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 Revisions: | -------------------------------------+------------------------------------- Adam Foltzer mentioned to me at ICFP that it would be nice if GHC had a "debug" mode that automatically inserted CallStack IPs in every function signature. Then you could easily get nice, fairly complete, call-stacks during development. Of course you could already do this with judicious use of CPP macros, but that's quite tedious (and error prone). As an example, consider {{{#!hs module A where foo xs = head xs head :: [a] -> a head (x:xs) = x head _ = error "bad" }}} Compiling `A` in this mode should result in the following signature {{{#!hs module A where foo :: (?callStack :: CallStack) => [a] -> a head :: (?callStack :: CallStack) => [a] -> a }}} I have a few concerns with this though: 1. We're '''changing''' a type signature that the user wrote. It would be a well-defined and consistent change across the whole module, but it's still unsettling. 2. How do we handle a function that already has a CallStack IP? {{{#!hs bar :: (?stk :: CallStack) => [a] -> a }}} If we're aiming for consistent insertion of CallStacks everywhere, it might make sense to remove the `?stk :: CallStack` and insert a `?callStack :: CallStack`, so they'll be appended correctly. But here again we'd be changing a user-written type signature. Furthermore, `bar` might call a function from a different module (or package) that hasn't been given this consistent debug treatment, and this other module might expect that the CallStack be named `?stk`. 3. If the CallStack is not used, e.g. {{{#!hs null :: (?callStack :: CallStack) => [a] -> Bool null [] = True null (_:_) = False }}} it will trigger a redundant constraint warning. I think we could address this by bubbling up CallStack constraints in much the same way that other constraints are propagated, so {{{#!hs module A where foo xs = head xs head :: [a] -> a head (x:xs) = x head _ = error "bad" null [] = True null (_:_) = False }}} would get the signature {{{#!hs module A where foo :: (?callStack :: CallStack) => [a] -> a head :: (?callStack :: CallStack) => [a] -> a null :: [a] -> Bool }}} In other words, we would only infer a CallStack constraint for a function when the body induces a wanted CallStack constraint. 4. How would this interact with cabal packages? If I accidentally install a package in debug mode, all downsteam packages will be compiled against the CallStack-laden signatures. Seems like we might need a new "debug" way.. It's pretty clear to me that a debug mode would be useful (in fact I manually added a bunch of CallStacks to my code the other day, only to remove them once I was done debugging), but the concerns (particularly 4.) are substantial. There's also the question of how all of this interacts with the ongoing DWARF work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10811: Template Haskell does associated types poorly (printing & quoting)
by GHC 21 Sep '15

21 Sep '15

#10811: Template Haskell does associated types poorly (printing & quoting) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TemplateHaskell, TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-} module Bug where $([d| class C a where type F a type F a = a |]) }}} I get {{{ [d| class C a where type family F a F a = a |] ======> Bug.hs:6:7: Warning: Cannot desugar this Template Haskell declaration: class C a where type family F a F a = a }}} There are two problems here: 1. This really should work. 2. The pretty-printer here omits the `type` on the default definition for `F`. (The word `family` is optional there, but isn't actually wrong.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10811> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10895: "no output will be generated" should be an error, not a warning.
by GHC 21 Sep '15

21 Sep '15

#10895: "no output will be generated" should be an error, not a warning. -------------------------------------+------------------------------------- Reporter: gershomb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider a file "Test.hs" which has a "main" function but is declared as "module Test where..." If we attempt to compile it, we get the following warning: {{{ Warning: output was redirected with -o, but no output will be generated because there is no Main module. }}} This should be upgraded from a warning to an error. This would help e.g. Cabal, because such warnings do not lead to a failure of the wrapping Cabal process, which is confusing to end-users. For gory details, see e.g. discussion at https://github.com/haskell/cabal/issues/1847 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10895> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #365: GHC dies silently with faulty preprocessor
by GHC 21 Sep '15

21 Sep '15

#365: GHC dies silently with faulty preprocessor -------------------------------------+------------------------------------- Reporter: josefs | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T365 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1256 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/365#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #365: GHC dies silently with faulty preprocessor
by GHC 21 Sep '15

21 Sep '15

#365: GHC dies silently with faulty preprocessor -------------------------------------+------------------------------------- Reporter: josefs | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T365 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1256 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * testcase: => T365 * differential: => Phab:D1256 Comment: Added a patch so it doesn't silently die. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/365#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5296: Add explicit type applications
by GHC 20 Sep '15

20 Sep '15

#5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: #4466 | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for the suggestion. Unfortunately, I think that `?a` looks too much like !ImplicitParams. But I do like the general idea. Here's a very, very radical thought: what if we use color? We could print `forall b. Num a => b -> (a, b)` but put `a` in a different color. (Even though it's a bit of a lie, I prefer putting the `forall b` before the `Num a`, only because Haskellers are much more used to that ordering.) Non-colored terminals still get all the information they need: that `b` is available for type application whereas `a` is not. But someone with color could see the needed information very easily. But something tells me it would be a major plumbing job to get color output... :( -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5296: Add explicit type applications
by GHC 20 Sep '15

20 Sep '15

#5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: #4466 | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Comment (by WrenThornton): Replying to [comment:17 goldfire]: > I have two open design questions: > > 1. What to do with `:type` in GHCi? Suppose we have `pair :: forall a. a -> forall b. b -> (a,b)`. I ask `:type pair 3`. The real type of this expression is `forall b. b -> (a0, b)`, where `a0` is the type of the overloaded `3`. The problem is that this type loses the fact that we need `Num a0`. We could say `forall b. Num a0 => b -> (a0, b)`, which is a little closer. Would we report that without `-fprint-explicit-foralls`? It would be wrong to say `forall a b. Num a => b -> (a, b)` (as is done today, even with this patch) because we can't instantiate `a` with a further visible type application. IMO, the type `forall a b. Num a => b -> (a, b)` is wrong for the expression `(pair 3)` aka `(pair @a (fromInteger @a $3))`, because the type `a` is fixed, albeit unknown. My first inclination would be to say those expressions have type `iota a. Num a => forall b. b -> (a, b)`. Of course, I wouldn't expect most folks to know anything about the `iota` quantifier, so I probably wouldn't print it that way. Do we have a notation for metavariables yet? We could say `Num ?a => forall b. b -> (?a, b)` supposing `?a` is the way we write a metavariable (rather than that syntax being used by ImplicitParams). > 2. It would be nice to be able to say `3 @Int` instead of `(3 :: Int)`. I agree with spj here. There's not really any benefit in terms of expressibility nor brevity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0