September 2015 - ghc-tickets

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 19 Sep '15

19 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

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

19 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 -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7830: Error: operand out of range
by GHC 19 Sep '15

19 Sep '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by trommler): * owner: => trommler -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1465: Type errors due to different package versions are a bit cryptic
by GHC 18 Sep '15

18 Sep '15

#1465: Type errors due to different package versions are a bit cryptic -----------------------------------------------+--------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.1 Component: Compiler (Type checker) | Version: 6.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Test Case: tcfail182, bug1465, mod180 | Unknown/Multiple -----------------------------------------------+--------------------------- Comment (by Edward Z. Yang <ezyang@…>): In [changeset:"a8406f81a5da077d1c4b9995654ca9972f39130c/ghc" a8406f81/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a8406f81a5da077d1c4b9995654ca9972f39130c" Pass TEST_HC_OPTS in bug1465 and T5792. Signed-off-by: Edward Z. Yang <ezyang(a)cs.stanford.edu> Test Plan: validate Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1250 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1465#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10580: rejected emails for Trac registrations from https://ghc.haskell.org/trac/haskell-prime
by GHC 18 Sep '15

18 Sep '15

#10580: rejected emails for Trac registrations from https://ghc.haskell.org/trac /haskell-prime -------------------------------------+------------------------------------- Reporter: imz | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I can't receive the confirmation email for my registration as i_m_z_ (with email address imz at altlinux.org) from https://ghc.haskell.org/trac /haskell-prime . The reason apparently is the one that often comes up with automatically sent confirmation email from such site, and has been described at http://en.altlinux.org/Non- delivery_of_email_sent_by_automated_services_to_altlinux.org : your server doesn't pass "sender-callback-verification" Please make your service better and make possible for more people to receive their confirmation messages needed to complete their registration -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10580> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!)
by GHC 18 Sep '15

18 Sep '15

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) -------------------------------------------+------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- attached is an example where the type checker isn't "computing" in the closed type families, or at least doing a one step reduction. this makes sense, given that type families only compute when instantiated... But if we could partially evaluate closed type families (or at least do a one step reduction), the attached example code would type check! interestingly, depending on what order the cases for the PSum are written, the type error changes! I guess I want an "eager matching" closed type family, that when partially instantiated will patch on the first pattern it satisfies, to complement ordered type families. attached is a toy example where I otherwise need an unsafeCoerce to make things type check -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8423> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9516: unsafeUnmask unmasks even inside uninterruptibleMask
by GHC 18 Sep '15

18 Sep '15

#9516: unsafeUnmask unmasks even inside uninterruptibleMask -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Control.Exception exports {{{#!hs allowInterrupt :: IO () allowInterrupt = unsafeUnmask $ return () }}} with documentation: ''When invoked inside `mask`, this function allows a blocked asynchronous exception to be raised, if one exists. It is equivalent to performing an interruptible operation, but does not involve any actual blocking. When called outside `mask`, or inside `uninterruptibleMask`, this function has no effect.'' However, this is not actually true: `unsafeUnmask` unmasks exceptions even inside `uninterruptibleUnmask`, as the attached test demonstrates (the test uses a foreign call just to have something non-interruptible but still observable; in particular, doing a `print` ''is'' interruptible because it uses an `MVar` under the hood). I think it is possible to define a better `unsafeUnmask` in user-land: {{{#!hs interruptible :: IO a -> IO a interruptible act = do st <- getMaskingState case st of Unmasked -> act MaskedInterruptible -> unsafeUnmask act MaskedUninterruptible -> act }}} but it still seems to be that we should either (i) change the behaviour of unsafeUnmask, or (ii) provide a version of `unsafeUnmask` with the behaviour as described and then change `allowInterrupt` to use that new version of `unsafeUnmask`, or at the very least (iii) change the documentation. (One question with the above definition of `interruptible` is what happens when we ''nest'' `mask` and `uninterruptibleMask`?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10893: Consistent error message suggestions for using language extensions
by GHC 18 Sep '15

18 Sep '15

#10893: Consistent error message suggestions for using language extensions -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I saw this error today in 7.10.2: {{{ Parse error: naked expression at top level Perhaps you intended to use TemplateHaskell }}} I'm glad it suggests using !TemplateHaskell; however, the suggestion seems incomplete. I did in fact intend to use Template Haskell, but I think this suggestion implies the ''language extension'' though it doesn't explicitly say so. I believe other error message suggestions are more explicit about mentioning language extension, e.g. {{{use -XFlexibleContexts}}}, which refers to the flag. I'm just bringing this issue up to request a consistent error message suggestion format for language extensions that explicitly mentions “language extension” or {{{-X}}}. (It may be that the above message is the only one not doing that; I haven't checked.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10893> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 18 Sep '15

18 Sep '15

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 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 erikd): * cc: erikd (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0