- ghc-tickets - Haskell.org

Re: [GHC] #2496: Invalid Eq/Ord instances in Data.Version
by GHC 06 May '15

06 May '15

#2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D395 -------------------------------------+------------------------------------- Comment (by zilinc): I feel it's too late to object, so I'll ask a question instead. I'm developing a software, in which I use the `VersionTags` field to store the git commit hash in order to know under which git revision my software is compiled. It's implemented by a hook in `Setup.hs`. So that the `showVersion` function can print something like `MySoftware 2.3.0.0-ce78942aed`, which is really handy for development. With the new changes in GHC, is there anywhere that I can put this piece of info? Or are you going to create another field in `PackageDescription` to keep extra notes? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2496#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10387: toRational should error out on NaN and Infinity values for Double/Floats
by GHC 06 May '15

06 May '15

#10387: toRational should error out on NaN and Infinity values for Double/Floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The current implementation of `toRational` for `Float`/`Double` types accept `NaN` and `Infinity` values and produce results. For `Infinity` the result nicely maps back to `Infinity`: {{{#!hs Prelude> fromRational (toRational (1/0)) :: Double Infinity Prelude> fromRational (toRational (-1/0)) :: Double -Infinity Prelude> }}} But the same isn't true for NaNs: {{{#!hs Prelude> fromRational (toRational (0/0)) :: Double -Infinity }}} Also, these results are probably architecture specific. In any case, I think `toRational` should simply error out if it receives `NaN` or `Infinity`, as there are really no legitimate values we can map them to, even though we might be able to complete the round-trip correctly in case if infinities. The following just doesn't make sense: {{{#!hs Prelude> toRational (1/0) 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 % 1 }}} So, I propose the `toRational` instance for Float/Double's should simply recognize `NaN` and `Infinite` values and throw an error. [Note that this is also how the HW implementations for the corresponding conversions work, raising a floating-point-exception (in the unmasked case). See `CVTPS2PI`/`CVTPS2DQ` etc., for instance, in x86.] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10387> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10235: Get profiling info without stopping program
by GHC 06 May '15

06 May '15

#10235: Get profiling info without stopping program -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I frequently want to know profiling information for web servers in production. Unfortunately there doesn't seem to be a way to trigger this without stopping the program, which might annoy my users. My ideal would be to able to call "dumpProfile :: Filename -> IO()" and then call that from a timer thread. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9851: Hoopl library in GHC hides runWithFuel / version number clash
by GHC 05 May '15

05 May '15

#9851: Hoopl library in GHC hides runWithFuel / version number clash -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The hoopl library on hackage exposes runWithFuel in Compiler.Hoopl. This function is used in the examples distributed with the library (in the testing directory). The version of hoopl distributed in GHC does not expose runWithFuel. Further, the version number of the GHC packaged hoopl is identical to the version number of the hoopl library on hackage. This is (1) confusing, since the haddock docs on hackage for the version in use on the system by default is not accurate, and (2) annoying, since you cannot get the version on hackage by just running a cabal install. Instead, you have to download the package, update the version number, and then cabal install. The fix seems to involve one or both of the following: (1) Bump the version number of hoopl on hackage. (2) Expose runWithFuel in the version distributed with GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9851> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #3046: Generalized newtype deriving with associated types
by GHC 05 May '15

05 May '15

#3046: Generalized newtype deriving with associated types -------------------------------------+------------------------------------- Reporter: LouisWasserman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Correct; #8165 is the relevant ticket, and has a good discussion string. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3046#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10108: Dramatic slowdown with -O2 bytestream and list streams combined.
by GHC 05 May '15

05 May '15

#10108: Dramatic slowdown with -O2 bytestream and list streams combined. -------------------------------------+------------------------------------- Reporter: Truman | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: break_in.hs | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In a small testcase intended to filter log files from stdin, I found that using bytestreams and list streams in combination worked fine when compiled without optimization, but runtime performance slowed down by a factor of about 3600 when I compiled with -O2. Changing the import of Data.List.Stream to Data.List gets rid of the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10108> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9530: min / max do not always return a NaN when one of the arguments is NaN
by GHC 05 May '15

05 May '15

#9530: min / max do not always return a NaN when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Easy (less than 1 | result at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I assume that this is well-known, but it tripped me up: {{{ Prelude> let inf = 1/0 Prelude> let nan = 0/0 Prelude> min nan inf Infinity Prelude> min inf nan NaN Prelude> min 3 nan NaN Prelude> min nan 3 3.0 Prelude> max nan inf NaN Prelude> max inf nan Infinity Prelude> max 3 nan 3.0 Prelude> max nan 3 NaN }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9530> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10381: Type-checking failure with RankNTypes and RebindableSyntax
by GHC 05 May '15

05 May '15

#10381: Type-checking failure with RankNTypes and RebindableSyntax -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE RebindableSyntax, RankNTypes #-} module Bug where import Prelude ( String, undefined ) newtype Cont r a = Cont { runCont :: (forall i. a i -> r) -> r } (>>=) :: Cont r a -> (forall i. a i -> Cont r b) -> Cont r b ma >>= fmb = Cont (\k -> runCont ma (\a -> runCont (fmb a) k)) fail :: String -> Cont r a fail = undefined return :: a i -> Cont r a return x = Cont (\k -> k x) foo :: Cont r [] foo = do bar <- foo return bar }}} I get {{{ Bug.hs:21:3: Couldn't match type ‘i0’ with ‘i’ because type variable ‘i’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: [i] -> Cont r [] at Bug.hs:21:3-12 Expected type: Cont r [] -> ([i0] -> Cont r []) -> Cont r [] Actual type: Cont r [] -> (forall i. [i] -> Cont r []) -> Cont r [] In a stmt of a 'do' block: bar <- foo In the expression: do { bar <- foo; return bar } In an equation for ‘foo’: foo = do { bar <- foo; return bar } }}} Yet, {{{ baz :: Cont r [] baz = baz >>= \bar -> return bar }}} at the end of this file compiles just fine. I had thought that `foo` and `baz` are entirely equivalent. Note that, with normal `do` notation, it ''is'' possible to do a GADT-like pattern-match with `<-`, without anyone's brain exploding. Some background: I'm attempting to write a type-checker for a simply-typed lambda calculus that uses GADTs to help me write the evaluation functions. The actual lambda-calculus bit has gone swimmingly; you can see it [https://github.com/goldfirere/glambda/blob/master/Language/Glambda/Exp.hs here]. But now I'm writing a type-checker, which has to take a possibly- ill-typed expression of type `UExp` and convert it to an `Exp ctx ty`, which is guaranteed to have type `ty` in context (a list of types) `ctx`. I can't just write {{{ check :: UExp -> Maybe (Exp '[] ty) }}} because the type has to be an ''output''. I could use existentials, but I find continuation-passing style to be easier to work with. But then the syntax goes all terrible. So, I want the `Cont` monad. Except that doesn't deal with these existentially-bound type variables at all. And, without doing any category theory, I have a very strong hunch that my CPS-with- extra-type-variables does not form a Monad. But, no matter, I'll just use `RebindableSyntax` and define my enhanced `Cont` not-a-monad with appropriate operators, and get my nice syntax back. But it doesn't work, as we see with this ticket. :( Clearly, this isn't really blocking me, but it makes me a touch sad not to use the nice syntax. `foo` fails to type-check in both 7.8 and 7.10, although the error messages are quite different (7.10 is an improvement). `baz` type-checks in both. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10306: Calling reify on Any or built-in type families causes panic
by GHC 04 May '15

04 May '15

#10306: Calling reify on Any or built-in type families causes panic -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #9840 Differential Revisions: Phab:D841 | -------------------------------------+------------------------------------- Both `reify ''Any` and `reify ''(+)` (where `(+)` is the built-in operation on type-level naturals) result in a panic `TcSplice.reifyFamFlavour: not a type family`. I came across this while working on #9840 and have a fix as part of Phab:D841. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10306> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #8028: Panic on degenerate closed type family
by GHC 04 May '15

04 May '15

#8028: Panic on degenerate closed type family -------------------------------------------------+------------------------- Reporter: monoidal | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+------------------------- Comment (by Adam Gundry <adam@…>): In [changeset:"4efa421327cf127ebefde59b2eece693e37dc3c6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4efa421327cf127ebefde59b2eece693e37dc3c6" Permit empty closed type families Fixes #9840 and #10306, and includes an alternative resolution to #8028. This permits empty closed type families, and documents them in the user guide. It updates the Haddock submodule to support the API change. Test Plan: Added `indexed-types/should_compile/T9840` and updated `indexed-types/should_fail/ClosedFam4` and `th/T8028`. Reviewers: austin, simonpj, goldfire Reviewed By: goldfire Subscribers: bgamari, jstolarek, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D841 GHC Trac Issues: #9840, #10306 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8028#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0