September 2014 - ghc-tickets

Re: [GHC] #8026: DatatypeContexts should be fixed, not deprecated
by GHC 22 Sep '14

22 Sep '14

#8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by yokto): I like the idea of fixing this too. The main Idea would be to hide Contexts from sight. As an example of how this could be useful consider Num were a newtype instead of a type class {{{ newtype (Prelude.Num n) => Num n = Num n newtype Int = Num Prelude.Int (+) :: Num n -> Num n -> Num n }}} This would mean you could actually make instances {{{ instance SomeClass (Num n) }}} that don't conflict with all other instances {{{ instance (Num n) => SomeClass n instance SomeClass Char }}} crash and even if you enable ugly extensions like UndecidableInstances this can not fix your problems if you want to use type families or functional dependencies. you can not make an instance {{{ class SomeClass a b | a -> b instance (Num n) => SomeClass n b }}} without immediately blocking all other possible Instances. Maybe these DatatypeContexts based containers are a bit less flexible than common classes in that they don't mix, but if you know they don't have to mix it makes instances a lot easier and safer. of course you can always add the context explicitly but it would be nice if ghc infer them. As gidyn said I don't think this would change the type system overly much. You would just get contexts that don't need not be explicitly stated. Every time you do context checks you can easily derive them from the type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8026#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8918: Network package doesn't load under GHC 7.8 RC on windows (?)
by GHC 22 Sep '14

22 Sep '14

#8918: Network package doesn't load under GHC 7.8 RC on windows (?) -------------------------------------+--------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- (Please note that I am not certain that this issue is related to the 7.8 release candidate specifically, it may be some peculiarity of my system. But the same thing does work for me under 7.6.3 on the same machine. I don't understand exactly what the message is complaining about, so I don't feel confident in making a diagnosis. I don't know if the problem is me, the library, or ghc.) Under the GHC 7.8 rc1 build for Windows that I installed, I can't load the network package. In the course of upgrading one of my projects, I cabal install'd the network-conduit package, and network is one of the dependencies. The install worked fine, with the usual sprinkling of deprecation warnings and "rule might not fire because..." warnings, nothing that seemed unusual or alarming. I can't however actually load the package. {{{ GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.4.0 ... linking ... done. Loading package Win32-2.3.0.1 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.1 ... linking ... done. Loading package directory-1.2.0.2 ... linking ... done. Loading package base-unicode-symbols-0.2.2.4 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package transformers-base-0.4.1 ... linking ... done. Loading package monad-control-0.3.2.3 ... linking ... done. Loading package lifted-base-0.2.2.1 ... linking ... done. Loading package mmorph-1.0.2 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package resourcet-0.4.10 ... linking ... done. Loading package text-1.1.0.1 ... linking ... done. Loading package text-stream-decode-0.1.0.4 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package nats-0.1.2 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package semigroups-0.12.2 ... linking ... done. Loading package void-0.6.1 ... linking ... done. Loading package conduit-1.0.15.1 ... linking ... done. Loading package parsec-3.1.5 ... linking ... done. Loading package network-2.4.2.2 ... linking ... ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc.exe: C:\Users\Doug\Documents\GitHub\bird-brain\.cabal-sandbox\x86_64 -windows-ghc-7.8.20140130\network-2.4.2.2\libHSnetwork-2.4.2.2.a: unknown symbol `WspiapiGetNameInfo' ghc.exe: unable to load package `network-2.4.2.2' }}} (The good bit was way at the end of a line, so repeated where you can see it...) {{{ network-2.4.2.2\libHSnetwork-2.4.2.2.a: unknown symbol `WspiapiGetNameInfo' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8918> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 6

[GHC] #9624: "Unlikely constraint" recognition
by GHC 22 Sep '14

22 Sep '14

#9624: "Unlikely constraint" recognition -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Some constraints or combinations are relatively unlikely to appear in correct code, or at least correct code written by beginners. A few tiny examples: {{{#!hs (Integral a, Fractional a) => -- Possible, but rare, in correct code. (Integral a, RealFloat a) => -- Rather less possible in correct code. (Num a, Foldable a) => -- Possible, but unlikely for a beginner. (Fractional [a]) => (Show (A -> B)) => }}} The current error messages when constraints like these are not satisfied does nothing to suggest that they are unlikely to be correct or to explain to a beginner what kinds of mistakes can lead to errors like this. I imagine some people who teach classes using Haskell will have an idea of which specific things are worth singling out for a special explanation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9624> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9568: Type classes that fully cover closed kinds
by GHC 22 Sep '14

22 Sep '14

#9568: Type classes that fully cover closed kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When we have a closed kind (I think data kinds may be the only ones that are closed?), and a type class that takes only that kind as a parameter, and we have instances of the typeclass for every type in the kind, it would be nice if we didn't have to list it in the context of every function that uses it. Example: in `GHC.TypeLits`, this relationship exists between `Nat` and `KnownNat`, `Symbol` and `KnownSymbol`. It also arises in many of my uses of data kinds, because I often end up with a `KnownX` class that provides term-level things related to whatever the type is. The constraints tend to end up everywhere, which is noisy. As far as I can tell they don't really carry any information: a `KnownNat n` constraint where `n :: Nat` should be able to be discharged in the same way that something like `Show Bool` is, because regardless of which `n` we pick we know there will be an instance. (This is trickier for closed kinds like `Nat` and `Symbol` than for user- defined ones through the data kinds feature, because the former are inhabited by infinitely many types.) Perhaps we could have a pragma to inform the compiler that this situation exists for a certain typeclass, which the compiler could check in finite cases (like the ones arising for user-defined data kinds) by enumerating all the cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9617: Try to replace `quot` and `rem` with `quotRem` when possible
by GHC 21 Sep '14

21 Sep '14

#9617: Try to replace `quot` and `rem` with `quotRem` when possible -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If I define {{{#!hs myquot x y = fst (quotRem x y) myrem x y = snd (quotRem x y) bob :: Int -> Int -> Int bob x y = myquot x y + myrem x y }}} Then I get this beautiful thing with GHC 7.9 (I ''don't'' get anything beautiful in 7.8.3, so great work, compiler gurus!): {{{#!hs bob :: Int -> Int -> Int bob = \ (w_sWx :: Int) (w1_sWy :: Int) -> case w_sWx of _ { I# ww1_sWB -> case w1_sWy of _ { I# ww3_sWF -> case ww3_sWF of wild_aSo { __DEFAULT -> case quotRemInt# ww1_sWB wild_aSo of _ { (# ipv_aSr, ipv1_aSs #) -> I# (+# ipv_aSr ipv1_aSs) }; (-1) -> case ww1_sWB of wild1_aSu { __DEFAULT -> case quotRemInt# wild1_aSu (-1) of _ { (# ipv_aSx, ipv1_aSy #) -> I# (+# ipv_aSx ipv1_aSy) }; (-9223372036854775808) -> case overflowError of wild2_00 { } }; 0 -> case divZeroError of wild1_00 { } } } } }}} However, if I write {{{ jones :: Int -> Int -> Int jones x y = quot x y + rem x y }}} I don't get anything nice. What I'm thinking (perhaps out of ignorance) is that we might be able to use the `myquot` and `myrem` definitions if it's possible to get some sort of dead code elimination to recognize when one or the other is not used, at which point it can replace the `quotRemInt#` with `quotInt#` or `remInt#`. Then we can quit the silly `quotRem` dance in user code and just write what we actually mean. Of course, exactly the same thing applies to `divMod`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9617> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1042: Floating point exception
by GHC 21 Sep '14

21 Sep '14

#1042: Floating point exception -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: #8695 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Never mind. The check was elsewhere. Sorry folks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1042#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1042: Floating point exception
by GHC 21 Sep '14

21 Sep '14

#1042: Floating point exception -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: #8695 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1042#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1042: Floating point exception
by GHC 21 Sep '14

21 Sep '14

#1042: Floating point exception -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: #8695 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: igloo => * status: closed => new * resolution: fixed => Comment: I'm sorry to reopen an 8 year old bug, but I tripped over this today while attempting (unsuccessfully, so far) to write a version of `divModInt` that plays nice with CSE: {{{#!hs divModInt :: Int -> Int -> (Int, Int) (I# x) `divModInt` (I# y) = case x `divModInt#` y of (# q, r #) -> (I# q, I# r) divModInt# :: Int# -> Int# -> (# Int#, Int# #) x# `divModInt#` y# = case x' `quotRemInt#` y# of (# q, r #) -> (# q +# qadj, r +# radj #) where (# x', qadj, radj #) = if | isTrue# (x# ># 0#) && isTrue# (y# <# 0#) -> (# x# -# 1#, -1#, y# +# 1# #) | isTrue# (x# <# 0#) && isTrue# (y# ># 0#) -> (# x# +# 1#, -1#, y# -# 1# #) | otherwise -> (# x#, 0#, 0# #) }}} When I test this with {{{#!hs main = print $ divModInt minBound (-1) }}} I get a floating point exception. `GHC.Base.divMod` does not trip over this, even though it seems to be doing exactly the same arithmetic. As far as I can tell, this is ''supposed'' to be handled by `quotRemInt#` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1042#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2.
by GHC 21 Sep '14

21 Sep '14

#5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:17 thomie]: Here's an updated link to [http://research.microsoft.com/pubs/151917 /divmodnote-letter.pdf Daan Leijen's paper]. Euclidean div/mod, along with other benefits, works much better than Haskell div/mod with the idea I've been playing with of implementing `div`-like things and `mod`-like things using `divMod`-like things. In particular, CSE can do some really nifty stuff with either `quotRem` or `divModEuclidean`, but it has no hope with `divMod` (at least as it's currently implemented) in the general case, because the latter has complicated code that gets all torn up before it gets to CSE. I don't know if there's a way to fix that. It does work out if one or both of the operands is known and there's sufficient inlining. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5615#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7863: Verbosity level for quieter Template Haskell
by GHC 20 Sep '14

20 Sep '14

#7863: Verbosity level for quieter Template Haskell -------------------------------------+------------------------------------- Reporter: dolio | Owner: hvr Type: feature | Status: closed request | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Template | Keywords: linker Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #5647 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D232 | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed Comment: Please reopen if this is not what we want -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7863#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0