December 2017 - ghc-tickets

[GHC] #12372: bug: documentation for Control.Monad.guard not useful after AMP
by GHC 15 Dec '17

15 Dec '17

#12372: bug: documentation for Control.Monad.guard not useful after AMP -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since the AMP refactor, the documentation for `Control.Monad.guard` [1] is no longer useful for beginners. It simply gives the definition of `guard`, but in prose: {{{ guard b is pure () if b is True, and empty if b is False. }}} (and better to just use Haskell instead of prose here, no?) To use `guard` in a `MonadPlus`, you now need to know that `Alternative` is a super class of `MonadPlus`, and that `mzero = zero`. The documentation [2] for `MonadPlus` doens't mention `mzero = zero` in the default definition -- you must look at the source for that -- and the docs for `guard` don't mention `MonadPlus`. The documentation for `Control.Monad.guard` should suggest use with `MonadPlus`, and give an example (compare with the very helpful example for `Control.Monad.when`). A non-monadic example would also be useful. [1] https://hackage.haskell.org/package/base-4.9.0.0/docs/Control- Monad.html#v:guard [2] https://hackage.haskell.org/package/base-4.9.0.0/docs/Control- Monad.html#t:MonadPlus -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12372> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14582: Review and improve the Typeable API
by GHC 15 Dec '17

15 Dec '17

#14582: Review and improve the Typeable API -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: Typeable | 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 ticket is to track improvements in the `Typeable` API There are a number of points I'm uncomfortable about * `Data.Typable` is presumably meant to be the public API, and is fairly small. But `Data.Typeable.Internal` has a much larger API, which includes pattern synonyms and suchlike that appear to be for the benefit of clients, not just internal use. * The `Typeable` API has `type TypeRep = I.SomeTypeRep` which is different to the type-indexed `data TypeRep a` defined in `Data.Typeable.Internals`. This is exteremly confusing. Perhaps this is intended to be temporary, while we are moving over to the new type-indexed representation. But then what's the transition plan? * I cordially dislike this stuff about `IsApplication` in `Internals` ([https://git.haskell.org/ghc.git/commitdiff/1acb922bb1186662919c1dbc0af59658… this commit]). It's hard for me to understand what's going on. I believe that the two pattern synonyms `App` and `Con` are supposed to be exhaustive -- if so, let's just write a COMPLETE pragma. * The code has many uses of `unsafeCoerce`, whereas the drive of our "Typed reflection in Haskell" paper was to reduced the size of the trusted code base. I'd like to see a comment on each of those uses of `unsafeCoerce` to explain. * Do we really need `Con'` as well as `Con`? * The API could do with some careful documentation, in Haddock, but perhaps also an accomanying wiki page. It's tricky stuff. Here's the [wiki:Typeable Typeable wiki page] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14580: GHC panic (TypeInType) (the 'impossible' happened)
by GHC 14 Dec '17

14 Dec '17

#14580: GHC panic (TypeInType) (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci GHCi, version 8.3.20171208: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Kind Prelude Data.Kind> :set -XPolyKinds -XDataKinds -XTypeInType -XTypeOperators Prelude Data.Kind> type Cat ob = ob -> ob -> Type Prelude Data.Kind> data ISO' :: Cat i -> i -> i -> Type Prelude Data.Kind> type ISO cat a b = ISO' cat a b -> Type Prelude Data.Kind> type (a <--> b) iso cat = ISO (iso :: cat a b) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171208 for x86_64-unknown-linux): piResultTy k_a1x1[tau:1] a_a1wU[sk:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1144:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:951:35 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude Data.Kind> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14580> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14554: Core Lint error mixing
by GHC 14 Dec '17

14 Dec '17

#14554: Core Lint error mixing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- While trying to deeply embed ''Singletons''-style defunctionalization symbol application using the code from [http://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1014&context=com… System FC with Explicit Kind Equality], I ran into the following `-dcore- lint` error: {{{#!hs {-# Language UndecidableInstances, DataKinds, TypeOperators, KindSignatures, PolyKinds, TypeInType, TypeFamilies, GADTs, LambdaCase, ScopedTypeVariables #-} import Data.Kind import Data.Proxy type a ~> b = (a, b) -> Type type family (@@) (f::k ~> k') (a::k)::k' data IdSym0 :: Type ~> Type type instance IdSym0 @@ a = a data KIND = X | FNARR KIND KIND data TY :: KIND -> Type where ID :: TY (FNARR X X) FNAPP :: TY (FNARR k k') -> TY k -> TY k' data TyRep (kind::KIND) :: TY kind -> Type where TID :: TyRep (FNARR X X) ID TFnApp :: TyRep (FNARR k k') f -> TyRep k a -> TyRep k' (FNAPP f a) type family IK (kind::KIND) :: Type where IK X = Type IK (FNARR k k') = IK k ~> IK k' type family IT (ty::TY kind) :: IK kind where IT ID = IdSym0 IT (FNAPP f x) = IT f @@ IT x zero :: TyRep X a -> IT a zero = \case TFnApp TID a -> undefined }}} {{{ $ ghci -ignore-dot-ghci -dcore-lint ~/hs/123-bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /home/baldur/hs/123-bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): ASSERT failed! Bad coercion hole {a2UN}: (IT (a_a1S5 |> Sym (TY (Sym co_a2UC))_N) |> D:R:IK[0]) (IT (a_a1S5 |> Sym (TY (Sym co_a2UC))_N) |> D:R:IK[0]) nominal <(IT (a_a1S5 |> Sym (TY (Sym co_a2UC))_N) |> D:R:IK[0])>_N IT (a_a1S5 |> Sym (TY (Sym co_a2UC))_N) IT (a_a1S5[ssk:3] |> Sym (TY (Sym co_a2UC))_N) nominal Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1205:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcMType.hs:305:105 in ghc:TcMType Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1203:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcMType.hs:305:105 in ghc:TcMType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14554> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14581: coerce String type in annotations with OverloadedStrings enabled
by GHC 14 Dec '17

14 Dec '17

#14581: coerce String type in annotations with OverloadedStrings enabled -------------------------------------+------------------------------------- Reporter: mgmeier | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Compiling the following snippet fails with the error message for not being able to resolve the constraint IsString for the given annotation (I've chosen some random HLint annotation here): {{{#!hs {-# LANGUAGE OverloadedStrings #-} module Foo where {-# ANN module "HLint: ignore Use <$>" #-} }}} Stating the type explicitly works fine, changing the annotation like this: {{{#!hs {-# ANN module ("HLint: ignore Use <$>" :: String) #-} }}} Note: this is actually only a minor annoyance which may or may not be confusing to newcomers. However since annotations use the String type, wouldn't it be possible to resolve the constraint in this case / coerce the value when inside an annotation? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14581> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #481: Recompilation check fails for TH
by GHC 14 Dec '17

14 Dec '17

#481: Recompilation check fails for TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: TH_recompile Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I don't think there's any perf impact, the stability check is already being done. The problem you're most likely seeing is that the recompilation check for TH is more conservative than we need in many cases, because the compiler doesn't know what your TH code depends on so it has to assume the worst. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/481#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4020: Please consider adding support for local type synonyms
by GHC 14 Dec '17

14 Dec '17

#4020: Please consider adding support for local type synonyms -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 6.12.2 checker) | Resolution: | Keywords: type synonym 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 ezyang): Yeah, local type synonyms are probably the least controversial of "make global things possible locally" proposals. There are pretty clear semantics for how it works in all cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4020#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #393: functions without implementations
by GHC 14 Dec '17

14 Dec '17

#393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | Resolution: | Keywords: newcomer 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 ron): I am new to GHC dev and working on a patch for #393 as a way to learn my way around the codebase. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/393#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9364: GHCi (or haskeline?) confused by non-single-width characters
by GHC 14 Dec '17

14 Dec '17

#9364: GHCi (or haskeline?) confused by non-single-width characters -------------------------------------+------------------------------------- Reporter: cheater | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: linux, terminal, | Operating System: colour, color, prompt | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Hi, there's an issue in the GHCi prompt. To reproduce: 1. Do everything in Linux (I don't have other operating systems); I'm using a version of the gnome 2 gnome-terminal. 2. Use the following to colourise the prompt in GHCi: echo -e :set prompt '"\033[32;1m%s\033[34;1m>\033[0m "' >> ~/.ghc/ghci.conf 3. Import quite a few modules (say, 5 to 10 should be enough) 4. Give the prompt enough text that it wraps around. It's best if you start the text with -- so that it's a comment and doesn't produce any output. For example, say I entered "-- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb", I now see the following: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb (do note that the first set of b's is located on the same line as the prompt, and the second is located under the prompt) 5. Press Enter. You should now see: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> 6. Press Ctrl-P or the up arrow key to select the previous history item. You will now see the following: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 7. Press Ctrl-A or the Home cursor key to go to the beginning of the text entry, and then type X. You will now see the last prompt to be: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbX-- bbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 8. If you press Enter, you will find out that prompt was actually (without line breaks): X-- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb I tried resizing the terminal window to 45 chars to make the lines above shorter; I imported Data.Monoid and Data.Functor in a new GHCi. The prompt contained garbage, most likely badly wrapped escape codes. See attachment. As both likely are a single bug in disguise, I include both reports in this ticket. Creating a test case for whether things actually work in a terminal might be difficult, but creating test for whether things get wrapped correctly (and not testing how things work out in a terminal) should be simple if annoying. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14561: Panic on levity polymorphic very unsafe coerce
by GHC 13 Dec '17

13 Dec '17

#14561: Panic on levity polymorphic very unsafe coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE MagicHash #-} module LevityId where import GHC.Types import GHC.Prim levityPolymorphicId :: forall (a :: TYPE r). a -> a levityPolymorphicId = unsafeCoerce# }}} {{{ (GHC version 8.3.20170928 for x86_64-apple-darwin): runtimeRepPrimRep typePrimRep (a_aW0 :: TYPE r_aVZ) r_aVZ Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1144:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:358:5 in ghc:RepType runtimeRepPrimRep, called at compiler/simplStg/RepType.hs:344:5 in ghc:RepType kindPrimRep, called at compiler/simplStg/RepType.hs:307:18 in ghc:RepType typePrimRep, called at compiler/simplStg/UnariseStg.hs:666:8 in ghc:UnariseStg Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} As originally mentioned [https://github.com/ghc-proposals/ghc- proposals/pull/98#issuecomment-349727273 here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9