March 2015 - ghc-tickets

[GHC] #8780: abs for IEEE floating point is slightly wrong.
by GHC 08 Mar '15

08 Mar '15

#8780: abs for IEEE floating point is slightly wrong. ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Evaluating abs(-0) gives the answer -0. This unexpected since it breaks invariants like 1/(abs x) >= 0. So abs(-0) should be 0. This is also the norm for other languages. Together with this change, signum should also be changed so signum(-0) is -0. This maintains the invariant abs x * signum x == x. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10147: Clang CPP adds extra newline character
by GHC 08 Mar '15

08 Mar '15

#10147: Clang CPP adds extra newline character -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: cpp | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Running the following command (taken from the settings file) {{{ cat ImportsSemi.hs | gcc -E -undef -traditional -Wunicode -Wno-invalid-pp- token -Wno-unicode - > out.hs }}} on any file results in a file which has an extra newline character appended to the end. This result is different from when `gcc` is used as the preprocessor, in this case no extra newline is appended. I appreciate that this isn't important to most users but it is important for ghc-exactprint. With the extra newline character the EOF marker is moved one line further down. When we come to output the AST, we also get an extra newline at the bottom of the file which breaks roundtripping. {{{ > gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1831: reify never provides the declaration of variables
by GHC 08 Mar '15

08 Mar '15

#1831: reify never provides the declaration of variables -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by tomberek): * cc: tomberek@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1831#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10142: Documentation for Ix is contradictory around minimal definition
by GHC 07 Mar '15

07 Mar '15

#10142: Documentation for Ix is contradictory around minimal definition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.4 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The Haddock documentation for `Ix` [http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Ix.html here] says that the minimal definition requires `range`, `index`, and `inRange`. But then it says that the minimal definition requires `range` and `inRange`. It seems that Haddock is inferring a `MINIMAL` definition where none is in the code. Perhaps a `MINIMAL` should be added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10142> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable`
by GHC 07 Mar '15

07 Mar '15

#9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- comment:ticket:9111:16 explains that import-cycles containing `Data.Typeable.Internal` (which provides the `Typeable` class `AutoDeriveTypeable` needs to be loaded for being able to operate) inside `base` make it difficult to use `AutoDeriveTypeable`, as well as making it more difficult to de-cycle the `base` import-dependency graph (see also attachment:typeable_deps.pngtypeable_deps.png) This ticket is about trying to find a way to restructure `base` in order to allow to define the `Typeable` instances directly at the type's defining site (and thus allow the use of `AutoDeriveTypeable`) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 07 Mar '15

07 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:16 ekmett]: > Otherwise I'm going to have to start putting CPP around the set of directives for the module. Why CPP? Afaik, `{-# LANGUAGE ConstrainedClassMethods #-}` is supported since GHC 7.0.1 ... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 07 Mar '15

07 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by ekmett): FWIW- This started breaking some pre-existing code: https://hackage.haskell.org/package/semigroupoids-1.2.6/docs/src/Data- Functor-Alt.html#some Would having `FlexibleContexts` imply `ConstrainedClassMethods` as well also be too much to ask? Otherwise I'm going to have to start putting CPP around the set of directives for the module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5188: Runtime error when allocating lots of memory
by GHC 06 Mar '15

06 Mar '15

#5188: Runtime error when allocating lots of memory -----------------------------------+------------------------------------- Reporter: knyblad | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+------------------------------------- Changes (by George): * failure: None/Unknown => GHCi crash -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5188#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 06 Mar '15

06 Mar '15

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | TypeFamilies, Injective Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4259 | Test Case: | Blocking: | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:109 jstolarek]: > (I am assuming that also `->` classifies type families although, as you point out, this is not entirely accurate.) Right -- `->` does '''not''' classify type families in Haskell today. The only place where `->` describes a type family is in the output of GHCi's `:kind` operator. And, to get that to work, GHC has a gross hack in that GHCi relaxes the "type families must always be saturated" requirement, just to appease users who want to know the shape of their type families. (This gross hack is a great idea from a user's point of view, and I'm not at all suggesting removing it. But it is gross from a type system point of view.) Nowhere in a Haskell source text can `->` classify a type family. So, I think that fact describes the difference between our comments above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 06 Mar '15

06 Mar '15

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | TypeFamilies, Injective Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4259 | Test Case: | Blocking: | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:108 goldfire]: > Replying to [comment:105 dorchard]: > > what about adding a kind of injectives `>->`? e.g.`* >-> *`is the kind of injective type functions > > This is very much along the lines of what Jan and I proposed in our "Promoting Functions to Type Families" paper ([http://www.cis.upenn.edu/~eir/papers/2014/promotion/promotion.pdf here]). Not exactly, I think. At the moment `->` kind classifies term-level functions (non-injective, non-generative, can be partially applied), type constructors (injective, generative, can be partially applied) and type families (non-injective, non-generative, cannot be partially applied). In our paper we proposed a new kind to classify type functions (families) that are still non-injective and non-generative but can be partially applied just like term-level functions. We addressed the problem of partial application, not injectivity. > GHC assumes all function types (that is, types with kinds that are headed by `->`) are ''generative'' and ''injective''. (...) Thus, the kind `->` denotes a generative, injective function. Are you sure? I would say this is true only for type constructors but perhaps I'm missing something. (I am assuming that also `->` classifies type families although, as you point out, this is not entirely accurate.) Anyway, I can imagine introducing a new kind to distinguish between injective and non-injective applications but, given that we might want a new kind to distinguish between things that can and can't be partially applied at the type level, this does not seem like a good choice. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:109> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0