September 2014 - ghc-tickets

Re: [GHC] #6018: Injective type families
by GHC 18 Sep '14

18 Sep '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): A nice syntax proposal showed up on Haskell-cafe. The idea is to allow user to actually introduce a variable that names the result: {{{#!hs type family Id a :: (result :: *) | result -> a where type family F a b c :: (d :: *) | d -> a b c type family G a b c :: (foo :: *) | foo-> a b where type family Plus a b :: (sum :: Nat) | sum a -> b, sum b -> a where type family H a b c :: (xyz :: *) | xyz a -> b c, xyz b -> a c }}} No new keywords, so we get full backwards compatibility. I'm only wondering how this would interact with kind signatures for the result, which we allow now. Above I assumed that if a programmer wants to name the result she must supply a kind annotation. This might be a bit inconvenient. On the other hand I think that the range of possible names for type variables and kinds is disjoint, so we may actually guess whether the user means the kind of the result or its name by looking whether the identifier is capitalized. So we could just write: {{{#!hs type family Id a :: result | result -> a where type family F a b c :: d | d -> a b c type family G a b c :: foo | foo-> a b where type family Plus a b :: sum | sum a -> b, sum b -> a where type family H a b c :: xyz | xyz a -> b c, xyz b -> a c }}} The only caveat I see is that user might accidentally write `type family Plus a b :: nat` instead of `type family Plus a b :: Nat` and then get some weird compilation errors if the kind signature was essential to make the code compile. Still, I like this proposal best of all made so far. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:68> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8097: internal error: getMBlock: mmap: Operation not permitted
by GHC 18 Sep '14

18 Sep '14

#8097: internal error: getMBlock: mmap: Operation not permitted ------------------------------+---------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+---------------------------------- I get the following: {{{ <interactive>: internal error: getMBlock: mmap: Operation not permitted (GHC version 7.4.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} when running {{{parseOnly queryKeyParse (Data.Text.pack "hello")}}} where: {{{ queryKeyParse :: Attoparsec.Parser [T.Text] queryKeyParse = do top <- Attoparsec.takeTill (=='[') keys <- many key return (top:keys) where key = many (Attoparsec.char '[') *> Attoparsec.takeTill (==']') <* many (Attoparsec.char ']') }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8097> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7353: Make system IO interruptible on Windows
by GHC 18 Sep '14

18 Sep '14

#7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.1 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by martin-bailey): * cc: hvr, ekmett (added) Comment: Is anyone currently working on an IO manager for Windows? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7353#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9559: "Illegal equational constraint" that might not be the users fault
by GHC 17 Sep '14

17 Sep '14

#9559: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | 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 you try the latest cabal head and GHC together as of 2014.09.04, and then you try to install statistics, you'll see an error like the following, which does not occur in GHC 7.8.3: {{{ cabal-1.21 install -w ghc-7.9.20140904 Resolving dependencies... Configuring statistics-0.13.2.1... Building statistics-0.13.2.1... Preprocessing library statistics-0.13.2.1... [ 1 of 46] Compiling Statistics.Test.Internal ( Statistics/Test/Internal.hs, dist/build/Statistics/Test/Internal.o ) [ 2 of 46] Compiling Statistics.Test.Types ( Statistics/Test/Types.hs, dist/build/Statistics/Test/Types.o ) [ 3 of 46] Compiling Statistics.Internal ( Statistics/Internal.hs, dist/build/Statistics/Internal.o ) [ 4 of 46] Compiling Statistics.Transform ( Statistics/Transform.hs, dist/build/Statistics/Transform.o ) Statistics/Transform.hs:113:3: Illegal equational constraint Control.Monad.Primitive.PrimState m ~ s (Use GADTs or TypeFamilies to permit this) When checking that ‘bitReverse’ has the inferred type bitReverse :: forall (m :: * -> *) b. (Control.Monad.Primitive.PrimMonad m, Control.Monad.Primitive.PrimState m ~ s) => Int -> Int -> m b In an equation for ‘mfft’: }}} (Indeed, adding the GADTs language pragma makes the type checker happy, as in the commit here: https://github.com/rrnewton/criterion/commit/3a2487176e92b6972560ab1abdfa09… ) Hmm, well, the source code in this case did not explicitly add the "~ s" constraint, the inference cooked it up. Is this a GHC bug in 7.9 or in 7.8? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9559> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9560: "Illegal equational constraint" that might not be the users fault
by GHC 17 Sep '14

17 Sep '14

#9560: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | 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 you try the latest cabal head and GHC together as of 2014.09.04, and then you try to install statistics, you'll see an error like the following, which does not occur in GHC 7.8.3: {{{ cabal-1.21 install -w ghc-7.9.20140904 Resolving dependencies... Configuring statistics-0.13.2.1... Building statistics-0.13.2.1... Preprocessing library statistics-0.13.2.1... [ 1 of 46] Compiling Statistics.Test.Internal ( Statistics/Test/Internal.hs, dist/build/Statistics/Test/Internal.o ) [ 2 of 46] Compiling Statistics.Test.Types ( Statistics/Test/Types.hs, dist/build/Statistics/Test/Types.o ) [ 3 of 46] Compiling Statistics.Internal ( Statistics/Internal.hs, dist/build/Statistics/Internal.o ) [ 4 of 46] Compiling Statistics.Transform ( Statistics/Transform.hs, dist/build/Statistics/Transform.o ) Statistics/Transform.hs:113:3: Illegal equational constraint Control.Monad.Primitive.PrimState m ~ s (Use GADTs or TypeFamilies to permit this) When checking that ‘bitReverse’ has the inferred type bitReverse :: forall (m :: * -> *) b. (Control.Monad.Primitive.PrimMonad m, Control.Monad.Primitive.PrimState m ~ s) => Int -> Int -> m b In an equation for ‘mfft’: }}} (Indeed, adding the GADTs language pragma makes the type checker happy, as in the commit here: https://github.com/rrnewton/criterion/commit/3a2487176e92b6972560ab1abdfa09… ) Hmm, well, the source code in this case did not explicitly add the "~ s" constraint, the inference cooked it up. Is this a GHC bug in 7.9 or in 7.8? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9560> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7015: Add support for 'static'
by GHC 17 Sep '14

17 Sep '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Luite, much of what you say is cast in terms of an underlying implementation, whereas my blog post focuses as exclusively as possible on the ''specification'' of what the programmer sees. Can you recast your suggestions in those terms? For example: * What does it mean to say that "GHC should explicitly keep track of all static metadata"? How would a programmer be able to tell whether or not GHC did so. That is, what programmer-visible behaviour do you seek? * Again "It should be possible to build a list (like the Static Pointer Table) at link time for a library". This is presumably a statement about the implementation but again you must have in mind some user-visible behavior? What is it? * Again "Static names would propagate like typeclass instances". I don't really know what this means, but specifically how would a programmer know if this happened? Static names are not visible to the programmer in the design I suggest; I use them only so I can say something about a possible implementation. All the programmer sees is ordinary Haskell values and types (with one new type constructor, `StaticPtr`. * "`StaticName` should be reasonably robust..." Again, you must have in mind some user-visible behaviour. Here I think I do know what you might mean. If you have a client and server talking to one another, and you recompile one having made only small internal changes, it should still inter-work with the original client. Something like that perhaps? Clearly this isn't yet a precise statement and you might want to make it so. And so on. Do you see what I mean? On the question of "I think it would be really useful if there was a way to send type details with a more complete serialization of the construction", I don't understand well enough. I tried (perhaps inadequately) to describe a design in which type security was guaranteed without sending type representations or fingerprints at all. Of course, some higher-level guarantees might be gained by sending type reps, but that would be up to a client library built on top of the facilities GHC provides. Are you asking for any GHC support here, or simply saying something about what a client library might or might not chose to do? Sorry to be dense. Thanks Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #427: Random.StdGen slowness
by GHC 17 Sep '14

17 Sep '14

#427: Random.StdGen slowness -------------------------------------+------------------------------------- Reporter: remit | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: | Version: libraries/random | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * owner: rrnewton => ekmett -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/427#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #427: Random.StdGen slowness
by GHC 17 Sep '14

17 Sep '14

#427: Random.StdGen slowness -------------------------------------+------------------------------------- Reporter: remit | Owner: rrnewton Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: | Version: libraries/random | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: rrnewton (added) Comment: The "thunk-bomb" problem should be fixed in random 1.1. The redesign question is still, however, open. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/427#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8899: StdGen does not generate 0
by GHC 17 Sep '14

17 Sep '14

#8899: StdGen does not generate 0 ------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `genRange` for `StdGen` returns `(0,2147483562)`. However, as far as I can tell, `StdGen` doesn't generate 0. This code performs 200 billion iterations of `next` on a `StdGen`. I ran it and it output `Nothing`. The probability that no 0 was generated by chance is approximately ''e^-200/2.147^'' =~ ''10^-40^''. {{{#!haskell import System.Random import Data.Int find0 :: StdGen -> Int64 -> Maybe Int64 find0 g0 n0 = aux g0 n0 where aux _ 0 = Nothing aux g r = let (v,g') = next g in if v == 0 then Just (n0 - r + 1) else aux g' (r-1) main :: IO () main = print $ find0 (mkStdGen 1234) 200000000000 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8899> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #4218: System.Random is way too lazy
by GHC 17 Sep '14

17 Sep '14

#4218: System.Random is way too lazy -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack Resolution: fixed | overflow Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 427, 7936 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * status: patch => closed * resolution: => fixed Comment: Shipped in random 1.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4218#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0