- ghc-tickets - Haskell.org

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

03 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 02 Jan '17

02 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 02 Jan '17

02 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

[GHC] #13047: Can create bindings of kind Constraint without ConstraintKind, only TypeFamilies
by GHC 01 Jan '17

01 Jan '17

#13047: Can create bindings of kind Constraint without ConstraintKind, only TypeFamilies -------------------------------------+------------------------------------- Reporter: pggiarrusso | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- This code compiles with GHC 8.0.1 (in either variant, with or without the definition of ApplyCtx Int in Foo Int. I think it shouldn't according to the docs in http://ghc.readthedocs.io/en/master/glasgow_exts.html?highlight=constraintK… #the-constraint-kind. If this is intended, I guess documenting it is acceptable. {{{ {-# LANGUAGE TypeFamilies #-} module Foo where import GHC.Exts (Constraint) class Foo a where type ApplyCtx a :: Constraint type ApplyCtx a = () instance Foo Int where type ApplyCtx Int = Show Int -- Commenting this out makes no difference. f :: ApplyCtx Int => Int f = 0 }}} Googling found https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-February/026151.html, but seems a different issue (and a non- bug). Also found https://ghc.haskell.org/trac/ghc/ticket/11715, which might be relevant (or not). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7647: UNPACK polymorphic fields
by GHC 31 Dec '16

31 Dec '16

#7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3990 #9655 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7647#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5075: CPR optimisation for sum types if only one constructor is used
by GHC 31 Dec '16

31 Dec '16

#5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Related: Phab:D2436 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5075#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #605: Optimisation: strict enumerations
by GHC 31 Dec '16

31 Dec '16

#605: Optimisation: strict enumerations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: #6135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): FWIW we can currently store strict enumerations as `Int#`s with Phab:D2424. Phab:D2436 allows returning `Int#` when returned enumeration is used strictly. Another patch is needed for extending demand analysis and passing `Int#` for strict enumerations. I actually have most of the code ready, but it needs rebasing it on current HEAD. IIRC some parts of the demand analysis were missing, but I can't remember exactly which parts. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/605#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles
by GHC 31 Dec '16

31 Dec '16

#7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by joeyhess): And here is the segfault info: {{{ *** Error in `./foo': double free or corruption (top): 0x0000000000b7b620 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f042ba4bbcb] /lib/x86_64-linux-gnu/libc.so.6(+0x76fa6)[0x7f042ba51fa6] /lib/x86_64-linux-gnu/libc.so.6(+0x7779e)[0x7f042ba5279e] /lib/x86_64-linux-gnu/libc.so.6(+0x21226)[0x7f042b9fc226] /lib/x86_64-linux-gnu/libc.so.6(iconv_close+0xf)[0x7f042b9fbabf] ./foo[0x40ef80] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7161#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0