- ghc-tickets - Haskell.org

Re: [GHC] #7259: Eta expansion of products in System FC
by GHC 20 Oct '17

20 Oct '17

#7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 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 Iceland_jack): What is the status of this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7259#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14374: group by using groupWith seems stricter than it need be
by GHC 19 Oct '17

19 Oct '17

#14374: group by using groupWith seems stricter than it need be -------------------------------------+------------------------------------- Reporter: newthin | 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: -------------------------------------+------------------------------------- Using TransformListComps: {{{#!hs is = [1..10] fs = map ((,) False) is ts = map ((,) True ) is a = [(the b, take 5 n) | (b,n) <- ts ++ fs, then group by b using groupWith] b = [(the b, take 5 n) | (b,n) <- ts ++ fs ++ [undefined], then group by b using groupWith] c = take 2 b }}} As of GHC 8.2.1, both b and c fail. While getting b to work seems difficult - it would require realizing that the domain of Bool has been satisfied - c seems like it might be more feasible to get working. As a motivator, this pattern is pretty common in data science, where we want to map elements of a large list to a small result domain and get examples of those elements with each result without iterating through the whole list. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14374> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13613: Simplify fixIO
by GHC 19 Oct '17

19 Oct '17

#13613: Simplify fixIO -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.0.1 Libraries | 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: -------------------------------------+------------------------------------- Now that we have `noDuplicate#`, I think we can make `fixIO` much simpler, and perhaps also faster, using something like what we do for `ST`. {{{#!hs data Res a = Res (# State# RealWorld, a #) fixIO f = IO $ \s -> let Res r@(# _s', a #) = unIO (noDuplicate >> f a) s in r }}} If `f` forks an `IO` thread demanding `a`, the `noDuplicate` should ensure that the computation is not re-entered, and the thread should wait for the main computation to complete. So I believe, anyway. The comment about eager blackholing here is a bit vague and doesn't give an example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13613> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14342: ghci fails to start with RebindableSyntax and OverloadedStrings
by GHC 19 Oct '17

19 Oct '17

#14342: ghci fails to start with RebindableSyntax and OverloadedStrings ----------------------------------------+------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- {{{ C:\Neil>ghci -XRebindableSyntax -XOverloadedStrings GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help <interactive>:1:39: error: Not in scope: `fromString' }}} GHCi exits immediately with the above error if using both rebindable syntax and overloaded strings. This behaviour prevents starting projects which use both extensions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14342> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14369: GHC warns an injective type family "may not be injective"
by GHC 19 Oct '17

19 Oct '17

#14369: GHC warns an injective type family "may not be injective" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple InjectiveFamilies | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilyDependencies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} data family Sing (a :: k) data instance Sing (z :: Maybe a) where SNothing :: Sing Nothing SJust :: Sing x -> Sing (Just x) class SingKind k where type Demote k = r | r -> k fromSing :: Sing (a :: k) -> Demote k instance SingKind a => SingKind (Maybe a) where type Demote (Maybe a) = Maybe (Demote a) fromSing SNothing = Nothing fromSing (SJust x) = Just (fromSing x) f :: forall (x :: forall a. Maybe a) a. SingKind a => Sing x -> Maybe (Demote a) f = fromSing }}} {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:26:5: error: • Couldn't match type ‘Demote a’ with ‘Demote a1’ Expected type: Sing (x a) -> Maybe (Demote a1) Actual type: Sing (x a) -> Demote (Maybe a) NB: ‘Demote’ is a type function, and may not be injective • In the expression: fromSing In an equation for ‘f’: f = fromSing • Relevant bindings include f :: Sing (x a) -> Maybe (Demote a1) (bound at Bug.hs:26:1) | 26 | f = fromSing | ^^^^^^^^ }}} That `NB: ‘Demote’ is a type function, and may not be injective` suggestion shouldn't be shown here, since `Demote` is definitely injective. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14365: Panic with (bogus?) deriving in hs-boot: newTyConEtadArity
by GHC 19 Oct '17

19 Oct '17

#14365: Panic with (bogus?) deriving in hs-boot: newTyConEtadArity -------------------------------------+------------------------------------- Reporter: happykitten | 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: -------------------------------------+------------------------------------- {{{ $ cat A.hs module Main where import {-# SOURCE #-} B main = return () $ cat B.hs module B where data Foo a = Foo a deriving (Functor) $ cat B.hs-boot module B where data Foo a deriving (Functor) $ ghc --make A.hs [1 of 3] Compiling B[boot] ( B.hs-boot, B.o-boot ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for i386-unknown-linux): newTyConEtadArity Foo Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/TyCon.hs:2149:27 in ghc:TyCon Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14350: Infinite loop when typechecking incorrect implementation (GHC HEAD only)
by GHC 19 Oct '17

19 Oct '17

#14350: Infinite loop when typechecking incorrect implementation (GHC HEAD only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 (Type checker) | 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: -------------------------------------+------------------------------------- On GHC HEAD, typechecking this program loops infinitely: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind data Proxy a = Proxy data family Sing (a :: k) data SomeSing k where SomeSing :: Sing (a :: k) -> SomeSing k class SingKind k where type Demote k :: Type fromSing :: Sing (a :: k) -> Demote k toSing :: Demote k -> SomeSing k data instance Sing (x :: Proxy k) where SProxy :: Sing 'Proxy instance SingKind (Proxy k) where type Demote (Proxy k) = Proxy k fromSing SProxy = Proxy toSing Proxy = SomeSing SProxy data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 type a @@ b = Apply a b infixl 9 @@ newtype instance Sing (f :: k1 ~> k2) = SLambda { applySing :: forall t. Sing t -> Sing (f @@ t) } instance (SingKind k1, SingKind k2) => SingKind (k1 ~> k2) where type Demote (k1 ~> k2) = Demote k1 -> Demote k2 fromSing sFun x = case toSing x of SomeSing y -> fromSing (applySing sFun y) toSing = undefined dcomp :: forall (a :: Type) (b :: a ~> Type) (c :: forall (x :: a). Proxy x ~> b @@ x ~> Type) (f :: forall (x :: a) (y :: b @@ x). Proxy x ~> Proxy y ~> c @@ ('Proxy :: Proxy x) @@ y) (g :: forall (x :: a). Proxy x ~> b @@ x) (x :: a). Sing f -> Sing g -> Sing x -> c @@ ('Proxy :: Proxy x) @@ (g @@ ('Proxy :: Proxy x)) dcomp f g x = applySing f Proxy Proxy }}} This is a regression from GHC 8.2.1/8.2.2, where it gives a proper error message: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:60:15: error: • Couldn't match expected type ‘Proxy a2 -> Apply (Apply (c x4) 'Proxy) (Apply (g x4) 'Proxy)’ with actual type ‘Sing (f x y @@ t0)’ • The function ‘applySing’ is applied to three arguments, but its type ‘Sing (f x y) -> Sing t0 -> Sing (f x y @@ t0)’ has only two In the expression: applySing f Proxy Proxy In an equation for ‘dcomp’: dcomp f g x = applySing f Proxy Proxy • Relevant bindings include x :: Sing x4 (bound at Bug.hs:60:11) g :: Sing (g x3) (bound at Bug.hs:60:9) f :: Sing (f x2 y) (bound at Bug.hs:60:7) dcomp :: Sing (f x2 y) -> Sing (g x3) -> Sing x4 -> (c x4 @@ 'Proxy) @@ (g x4 @@ 'Proxy) (bound at Bug.hs:60:1) | 60 | dcomp f g x = applySing f Proxy Proxy | ^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:60:27: error: • Couldn't match expected type ‘Sing t0’ with actual type ‘Proxy a0’ • In the second argument of ‘applySing’, namely ‘Proxy’ In the expression: applySing f Proxy Proxy In an equation for ‘dcomp’: dcomp f g x = applySing f Proxy Proxy • Relevant bindings include x :: Sing x4 (bound at Bug.hs:60:11) g :: Sing (g x3) (bound at Bug.hs:60:9) f :: Sing (f x2 y) (bound at Bug.hs:60:7) dcomp :: Sing (f x2 y) -> Sing (g x3) -> Sing x4 -> (c x4 @@ 'Proxy) @@ (g x4 @@ 'Proxy) (bound at Bug.hs:60:1) | 60 | dcomp f g x = applySing f Proxy Proxy | ^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14350> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13385: ghci fails to start when -XRebindableSyntax is passed
by GHC 19 Oct '17

19 Oct '17

#13385: ghci fails to start when -XRebindableSyntax is passed -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 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: -------------------------------------+------------------------------------- Running "ghci -XRebindableSyntax" yields the following output: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help <interactive>:1:6: error: Not in scope: ‘>>’ <interactive>:1:70: error: Not in scope: ‘>>’ <interactive>:1:135: error: Not in scope: ‘return’ }}} This appears to be a regression, as it does not occur with ghc-7.10.3. Originally reported as a stack issue by Michal Konecny - https://github.com/commercialhaskell/stack/issues/3043 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13385> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14367: Lazy evaluation can be invalidated
by GHC 19 Oct '17

19 Oct '17

#14367: Lazy evaluation can be invalidated -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Evaluating arguments only if and when they are needed. This is the first principle of lazy evaluation.\\ Example:\\ {{{ Prelude> let f True x y = x Prelude> f True 3 (3/0) 3 }}} Good answer! See this:\\ {{{ Prelude> f True 8 undefined 8 }}} and:\\ {{{ Prelude> f True undefined 8 *** Exception: Prelude.undefined CallStack (from HasCallStack): error, called at libraries\base\GHC\Err.hs:79:14 in base:GHC.Err undefined, called at <interactive>:2:8 in interactive:Ghci2 }}} These results are all correct because the evaluated expression (function) is non-strict.\\ The same expression below with a changed argument:\\ {{{ Prelude> f True 3 _ <interactive>:54:10: error: * Found hole: _ :: p20 Where: `p20' is an ambiguous type variable * In the third argument of `f', namely `_' In the expression: f True 3 _ In an equation for `it': it = f True 3 _ * Relevant bindings include it :: p1 (bound at <interactive>:54:1) }}} I understand this error, it is legitimate except that here, in this specific case, I would never use this expression.( i.e{{{_}}}) or the result of that expression if that result were to be used. Here the error message should not have priority. \\ This argument ( i.e {{{_}}}) does not need to be evaluated to calculate the result.\\ With Normal-Order Reduction, an expression is reduced only when absolutely necessary to continue the reduction.\\ So, here, who cares! Since this expression (i.e{{{_}}}), or the result is supposed never to be used.\\ It is the same for this example:\\ {{{ Prelude> f True 3 r <interactive>:55:10: error: Variable not in scope: r }}} Idem, here the error message should not have priority. About {{{r}}} here, who cares! \\ By contrast here in this other example,{{{r}}} must be in the scope to be used:\\ {{{ Prelude> let g x t = x + t + r <interactive>:56:21: error: Variable not in scope: r }}} Anyway,{{{(+)}}} is strict in both arguments.\\ I think leaving the priority to lazy evaluation will bring much more consistency in the results. Of course, ghc would take this error into account and send it after the compilation if needed. \\ These examples are not exaustive examples. See ticket [ticket:14355]. (although in this ticket, the thing is slightly different). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14367> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible
by GHC 19 Oct '17

19 Oct '17

#11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 7.11 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 helping a Haskell beginner today, we came across this behavior and I wondered why there wasn't already a ticket for this problem in the tracker. In fact, this is technically a duplicate of #3217, but that ticket is long (and it was difficult to find!) so I just want to file a new ticket to summarize what needs to be done. The essential problem is that a user is editing a file that looks like this: {{{ {-# LANGUAGE OverloadedStrings #-} module A where ... some code ... }}} and they load this into ghci with `ghci A.hs`. They then might reasonably type a string into the GHCi prompt and expect it to be overloaded... but it will not be! They had to have invoked GHCi with `ghci -XOverloadedStrings A.hs`. This behavior is unexpected and not very nice. The proposal is this: (from https://ghc.haskell.org/trac/ghc/ticket/3217#comment:15) GHCi should be changed so that at most one module is "fully open", currently denoted *M in GHCi's prompt. If a module M is "fully open", expressions typed at the GHCi prompt are interpreted (roughly) as if they were written in M itself. Specifically: * All the top-level things in the module are in scope * The per-module flags in {-# OPTIONS #-} and {-# LANGUAGE #-} pragmas * M's default declaration holds Note that currently more than one module can be fully open, and their top level scopes are merged. We propose to make that at most one. When compiling an expression typed on the GHCi command line: * Start with the baseline DynFlags * Apply flags specified on the original command-line * (Perhaps: apply flags specified by :set in this GHCi session. We aren't sure whether or not to do this.) * Apply GHCi baseline command-prompt flags (e.g. special defaulting rules) * Apply flags specified by :seti in this GHCi session * If there is a fully-open module M, apply flags specified in M itself. That is, flags in M get the last word. Implementing this plan will require some representation changes. In particular, since we need to apply M's source-code flags in two difference places, we really need to remember the diffs with M, perhaps as a `(DynFlags -> DynFlags)` function or something. See also: https://ghc.haskell.org/trac/ghc/ticket/3217#comment:28 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11469> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6