January 2017 - ghc-tickets

[GHC] #12534: GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects
by GHC 02 Jan '17

02 Jan '17

#12534: GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 7.10 rejects this datatype: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} module Bug where data T (a :: a) }}} {{{ $ /opt/ghc/7.10.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:1: Kind variable also used as type variable: ‘a’ In the data type declaration for ‘T’ }}} But GHC 8.0 accepts the above code! It appears that GHC implicitly freshens the kind-level `a` so as to have a different name, since the following modification to `T`: {{{#!hs data T a (a :: a) }}} Results in this error: {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:8: error: Conflicting definitions for ‘a’ Bound at: Bug.hs:5:8 Bug.hs:5:11 Bug.hs:5:16: error: Type variable ‘a’ used in a kind. Did you mean to use TypeInType? the data type declaration for ‘T’ }}} But with this modification: {{{#!hs data T (a :: a) a }}} You won't get an error message about `a` being used as both a kind and type: {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:9: error: Conflicting definitions for ‘a’ Bound at: Bug.hs:5:9 Bug.hs:5:17 }}} To make things even more confusing, this behavior doesn't seem to carry over to typeclass instances. For example: GHC 8.0 will (rightfully) reject this code: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} module Bug where data T (a :: a) class C x instance C (T (a :: a)) }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:16: error: Variable ‘a’ used as both a kind and a type Did you intend to use TypeInType? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12837: KnownNat and KnownSymbol should be abstract
by GHC 02 Jan '17

02 Jan '17

#12837: KnownNat and KnownSymbol should be abstract -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following patent nonsense: {{{#!hs {-# LANGUAGE FlexibleInstances #-} import GHC.TypeLits instance KnownNat n }}} This is accepted (albeit with a warning about the missing `natSing` method). I think it should be rejected, as should an instance of `KnownSymbol`. Compare doing the same thing with `Typeable`, which says: {{{ Class ‘Typeable’ does not support user-specified instances }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12837> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13003: improve documentation for typed TH and make it more discoverable
by GHC 02 Jan '17

02 Jan '17

#13003: improve documentation for typed TH and make it more discoverable -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- theres quite a sparsity of documentation and dearth of discoverability for typed TH in the Template Haskell Library haddocks and the GHC manual, this probably wouldn't be much work to make it vastly better. one specific two course of action might be a) adding to the template haskell library a module `Language.Haskell.TH.Typed` that only exports the stuff in `Language.Haskell.TH` that is needed for typed TH (namely the newtype `TExp` but not its constructor), plus perhaps the function `unTypeQ :: Q (TExp a) -> Q Exp` and additionally documents how to use typed TH splices and quotations. b) add a clear section to the manual that perhaps touches on some of this too? (its not clear if theres any real docs in the ghc manual on this :( ) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13042: Allow type annotations / visible type application in pattern synonyms
by GHC 02 Jan '17

02 Jan '17

#13042: Allow type annotations / visible type application in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple TypeApplications, PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data Lift f a = Pure a | Other (f a) data V0 a }}} To make a pattern synonym for `a -> Lift V0 a` I would like to be able to write either {{{#!hs pattern A a = Pure @V0 a }}} or {{{#!hs pattern B a = (Pure :: _ -> _ V0 _) a }}} to be equivalent to {{{#!hs pattern C :: a -> Lift V0 a pattern C a = Pure a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13052: unsafePerformIO duped on multithread if within the same IO thunk
by GHC 01 Jan '17

01 Jan '17

#13052: unsafePerformIO duped on multithread if within the same IO thunk -------------------------------------+------------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Unlike `unsafeDupablePerformIO`, an `unsafePerformIO` block is not supposed to be executed more than once when two threads race to evaluate it, and yet the following program detects that the counter is sometimes incremented twice: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# OPTIONS -O0 -threaded -rtsopts -with-rtsopts=-N #-} module Main where import Control.Concurrent import System.IO.Unsafe runThreads :: IO () -> IO () -> IO () runThreads body1 body2 = do var1 <- newEmptyMVar var2 <- newEmptyMVar _ <- forkIO $ do { !_ <- body1; putMVar var1 () } _ <- forkIO $ do { !_ <- body2; putMVar var2 () } takeMVar var1 takeMVar var2 main :: IO () main = do counter <- newMVar (0 :: Int) let sharedThunk = unsafePerformIO $ modifyMVar_ counter (return . (+1)) let sharedIO = return sharedThunk _ <- runThreads sharedIO sharedIO n <- takeMVar counter if n == 1 then main else print n }}} Note that optimizations are turned off, so this isn't due to inlining. In fact, if I inline `sharedIO` and write {{{#!hs _ <- runThreads (return sharedThunk) (return sharedThunk) }}} instead, the problem disappears. So it seems that in order to reproduce the problem, two threads must race to evaluate an IO thunk containing an `unsafePerformIO` block; a race to evaluate the `unsafePerformIO` block is not sufficient. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ...
by GHC 01 Jan '17

01 Jan '17

#12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12001 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Made this its own ticket, rather than using #12001. Are these worth adding? {{{#!hs pattern Cont :: ((a -> r) -> r) -> Cont r a pattern Cont a <- (runCont -> a) where Cont a = cont a pattern Writer :: (a, w) -> Writer w a pattern Writer a <- (runWriter -> a) where Writer a = WriterT (Identity a) pattern Reader :: (r -> a) -> Reader r a pattern Reader a <- (runReader -> a) where Reader a = reader a pattern State :: (s -> (a, s)) -> State s a pattern State a <- (runState -> a) where State a = state a }}} The mtl API was changed way back when (before advent of pattern synonyms) which caused some [http://stackoverflow.com/questions/14157090/has-the- control-monad-state-api-changed-recently confusion], [http://learnyouahaskell.com/for-a-few-monads-more LYAH] still uses `Writer`, `State` in their examples. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12767> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10