- ghc-tickets - Haskell.org

[GHC] #14542: Renamer / typechecker hang (UndecidableSuperClasses)
by GHC 24 Feb '18

24 Feb '18

#14542: Renamer / typechecker hang (UndecidableSuperClasses) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple UndecidableSuperClasses | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Adapted from [https://gist.github.com/ekmett/b26363fc0f38777a637d hask], this does not look like a normal superclass loop. Loop is avoided by removing `instance (Category p, Category q) => Category (Nat p q)`. {{{#!hs {-# language KindSignatures #-} {-# language PolyKinds #-} {-# language DataKinds #-} {-# language TypeFamilies #-} {-# language RankNTypes #-} {-# language NoImplicitPrelude #-} {-# language FlexibleContexts #-} {-# language MultiParamTypeClasses #-} {-# language GADTs #-} {-# language ConstraintKinds #-} {-# language FlexibleInstances #-} {-# language TypeOperators #-} {-# language ScopedTypeVariables #-} {-# language DefaultSignatures #-} {-# language FunctionalDependencies #-} {-# language UndecidableSuperClasses #-} {-# language UndecidableInstances #-} {-# language TypeInType #-} import GHC.Types (Constraint, Type) type Cat i = i -> i -> Type newtype Y p a b = Y { getY :: p b a } class (Functor p, Dom p ~ Op p, Cod p ~ Nat p (->), Ob (Op p) ~ Ob p) => Category (p :: Cat i) where type Op p :: Cat i type Op p = Y p type Ob p :: i -> Constraint class (Category (Dom f), Category (Cod f)) => Functor (f :: i -> j) where type Dom f :: Cat i type Cod f :: Cat j data Nat :: Cat i -> Cat j -> Cat (i -> j) instance (Category p, Category q) => Category (Nat p q) }}} I get {{{ $ ghci2 -ignore-dot-ghci -v /tmp/Hangs.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 8.3.20171122, stage 2 booted by GHC version 8.2.1 ... Loading package integer-gmp-1.0.1.0 ... linking ... done. Loading package base-4.11.0.0 ... linking ... done. *** Parser [source]: !!! Parser [source]: finished in 0.66 milliseconds, allocated 0.136 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.43 milliseconds, allocated 0.233 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.23 milliseconds, allocated 0.167 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.35 milliseconds, allocated 0.284 megabytes *** Parser [source]: !!! Parser [source]: finished in 0.21 milliseconds, allocated 0.197 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.52 milliseconds, allocated 0.268 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.23 milliseconds, allocated 0.113 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.46 milliseconds, allocated 0.334 megabytes *** Chasing dependencies: Chasing modules from: !!! Chasing dependencies: finished in 0.14 milliseconds, allocated 0.047 megabytes Stable obj: [] Stable BCO: [] unload: retaining objs [] unload: retaining bcos [] Ready for upsweep [] Upsweep completely successful. *** Deleting temp files: Deleting: *** Chasing dependencies: Chasing modules from: */tmp/Hangs.hs !!! Chasing dependencies: finished in 6.10 milliseconds, allocated 10.504 megabytes Stable obj: [] Stable BCO: [] unload: retaining objs [] unload: retaining bcos [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2017-11-28 22:14:57.810561584 UTC ms_mod = Main, ms_textual_imps = [(Nothing, GHC.Types)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file /tmp/Hangs.hs *** Checking old interface for Main (use -ddump-hi-diffs for more details): [1 of 1] Compiling Main ( /tmp/Hangs.hs, interpreted ) *** Parser [Main]: !!! Parser [Main]: finished in 2.63 milliseconds, allocated 4.821 megabytes *** Renamer/typechecker [Main]: }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13153: Several Traversable instances have an extra fmap
by GHC 24 Feb '18

24 Feb '18

#13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.1 Libraries | 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: -------------------------------------+------------------------------------- For example, we define {{{#!hs instance Traversable ZipList where traverse f (ZipList xs) = ZipList <$> traverse f xs }}} If the list is very short, the extra `fmap` could be bad. We can fix this by inlining the inner `traverse`. However, I suspect a better approach would be to add a method to `Traversable`: {{{#!hs mapTraverse :: Applicative f => (t b -> r) -> (a -> f b) -> t a -> f r mapTraverse p f xs = p <$> traverse f xs }}} but I need to work through whether this is enough power to solve enough problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11826: unsafe causes bug, news @ 11
by GHC 24 Feb '18

24 Feb '18

#11826: unsafe causes bug, news @ 11 -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- I know there has been plenty of levity here lately but here goes :) I didn't expect ‘isUndefined’ to be safe but this may be interesting to the devs (I am obedient and report it thusly and hereby-ly per GHC's request) {{{#!haskell % ghci -ignore-dot-ghci GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help Prelude> import Control.Exception Prelude Control.Exception> import System.IO.Unsafe Prelude Control.Exception System.IO.Unsafe> import Unsafe.Coerce Prelude Control.Exception System.IO.Unsafe Unsafe.Coerce> isUndefined x = unsafePerformIO $ catch ((unsafeCoerce x :: IO ()) >> return False) (const $ return True :: SomeException -> IO Bool) Prelude Control.Exception System.IO.Unsafe Unsafe.Coerce> isUndefined (succ True) True Prelude Control.Exception System.IO.Unsafe Unsafe.Coerce> isUndefined (succ False) <interactive>: internal error: stg_ap_v_ret (GHC version 8.1.20160117 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) % }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11826> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14799: QuantifiedConstraints: Problems with Typeable
by GHC 24 Feb '18

24 Feb '18

#14799: QuantifiedConstraints: Problems with Typeable -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints, wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This compiles {{{#!hs {-# Language GADTs, ConstraintKinds, ScopedTypeVariables, QuantifiedConstraints #-} import Data.Typeable data Ex cls where MkEx :: cls xx => xx -> Ex cls a :: Ex Typeable -> TypeRep a (MkEx (_::xx)) = typeRep @_ @xx Proxy -- b :: (forall xx. cls xx => Typeable xx) => Ex cls -> TypeRep -- b (MkEx (_::xx)) = typeRep @_ @xx Proxy c :: (forall xx. cls xx => Show xx) => Ex cls -> String c (MkEx xx) = show xx }}} but uncommenting `b` is too much: {{{ $ qc hs/189-bug.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/189-bug.hs, interpreted ) hs/189-bug.hs:12:20: error: • Could not deduce (Typeable xx) arising from a use of ‘typeRep’ from the context: forall xx. cls xx => Typeable xx bound by the type signature for: b :: forall (cls :: * -> Constraint). (forall xx. cls xx => Typeable xx) => Ex cls -> TypeRep at hs/189-bug.hs:11:1-60 or from: cls xx bound by a pattern with constructor: MkEx :: forall xx (cls :: * -> Constraint). cls xx => xx -> Ex cls, in an equation for ‘b’ at hs/189-bug.hs:12:4-15 • In the expression: typeRep @_ @xx Proxy In an equation for ‘b’: b (MkEx (_ :: xx)) = typeRep @_ @xx Proxy | 12 | b (MkEx (_::xx)) = typeRep @_ @xx Proxy | ^^^^^^^^^^^^^^^^^^^^ Failed, no modules loaded. Prelude> }}} This is maybe because of the `Typeable` solver. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14799> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12524: RFC: Allow prefixing result evaluated at GHCi prompt
by GHC 24 Feb '18

24 Feb '18

#12524: RFC: Allow prefixing result evaluated at GHCi prompt -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- Similar to `prompt`, `prompt-cont` (previously `prompt2`): allowing users to supply a prefix to evaluation results with `result` has two use cases I can think of {{{ :set prompt " ghci> " :set prompt-cont " ghci| " :set result " " }}} the desired outcome would be `↓` as indented code for IRC, also reddit code format: {{{ ghci> 1 + 2 + 3 6 ghci> reverse "hello" "olleh" }}} ---- The other case came from [https://twitter.com/rightfold/status/767301255140179968 this tweet] {{{ :set prompt "" :set result "-- " }}} {{{ 1 + 2 + 3 -- 6 reverse "hello" -- "olleh" }}} This can be copied/pasted back to a separate GHCi session where the result is ignored. ---- I haven't seen this feature in any other repl, I'm not sure if this would see much use. This wouldn't work with IO actions without some magic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #2893: Implement "Quantified constraints" proposal
by GHC 23 Feb '18

23 Feb '18

#2893: Implement "Quantified constraints" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5927 | Differential Rev(s): Phab:D4353 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #5927 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2893#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5927: A type-level "implies" constraint on Constraints
by GHC 23 Feb '18

23 Feb '18

#5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #2893 Comment: The "`Implies`" in {{{(c `Implies` Show)}}} is the `=>` in the quantified constraint `(c => Show)`. Quantified constraints also allow you to write `forall a. Monoid a`. Or, to put things another way, this is a duplicate of #2893, which tracks the implementation of `QuantifiedConstraints`. I'll close this ticket in favor of that one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5927#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14748: Infer context for Data instance of (data Foo f = Foo (f Bool) (f Int))
by GHC 23 Feb '18

23 Feb '18

#14748: Infer context for Data instance of (data Foo f = Foo (f Bool) (f Int)) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (based on WIP [https://phabricator.haskell.org/D4353 -XQuantifiedConstraints]) Could GHC infer the context for deriving `Data (Foo f)` (#12245)? {{{#!hs data Foo f = Foo (f Bool) (f Int) deriving stock Data {- Generates: instance (Typeable f, (forall xx. Data xx => Data (f xx))) => Data (Foo f) -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14748> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #855: Improvements to SpecConstr
by GHC 23 Feb '18

23 Feb '18

#855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * blocking: => 915 Comment: Sorry, didn't mean to remove that Blocking thing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #855: Improvements to SpecConstr
by GHC 23 Feb '18

23 Feb '18

#855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * blocking: 915 => Comment: Re: Specialising on lambdas. To have a concrete example to work on, I here is [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-hs stream-fusion.hs], which contains a minimal stream fusion harness using just `singletonS`, `enumFromToS`, `sumS`, `mapS` and `concatMapS`. There are three example functions `ex{1,2,3}` with increasing nesting of `concatMapS` that should all reduce to the same function `goal`. More examples can follow when we get these running. Currently, GHC HEAD (8.5, `8529fbba309cd692bbbb0386321515d05a6ed256`) produces [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-head-simpl-L436 this infamous piece of Core] ([https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-head-spec-L1387 -ddump-spec]) for `ex1`. The goal is to specialise `go` for the call-pattern including a lambda [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-head-simpl-L466-L470 here]. Before I found this ticket, I basically re-implemented part of what simonpj did, results in [https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc23… this commit]. I basically tracked `CallOcc`urrences similarly to `ScrutOcc`s. With this specialisation for lambdas, things currently look like [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-lam-simpl-L435 this]. The function has been specialised alright, but the free variables of [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-head-simpl-L466-L470 said lambda], which includes the constant `Step`, are passed to [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-lam-simpl-L453-L457 the specialisation as arguments]. We want to specialise for this new `Call` pattern! However, without `-fspec-constr-keen`, !SpecConstr will only fire when it finds a matching `ScrutOcc`. Looking at the output of [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-lam-spec-L1495-L1499 -ddump-spec] the corresponding `ScrutOcc` will only become visible in the specialised RHS, but we currently only specialise the original RHS. Even then, I imagine that in the general case we need a simplifier run in-between to reliably detect that we scrutinize the new parameter. But that's not actually a problem, because we can use `GHC.Types.SPEC` to tell the compiler to specialise without seeing an `ArgOcc`. Still, GHC needs to see a `Call` pattern with that constant argument, which will emerge [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-lam-spec-L1503-L1517 here], but only after the corresponding RULEs fired. Here are some ideas: 1. We can query the `exprFreeVarsList` [https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc23… #diff-992f9a53caac96c0e6303669d68a20e1R2163 here] and see which free variables of the lambda have known constant value and include these in the specialisation. This was somehow fruitless so far for this case, as the free var for the `Yield ...` wasn't included in the `ValueEnv`. Not sure if this is even enough to reach the fixed point in all cases. 2. Specialise specialisations (and fix anything non-terminating) (+ mini simplifier passes) + mini RULE engine. I'm uncomfortable with that much code duplication. 3. Include call-pattern specialisation in the Simplifier, for a radical change. On an abstract level, this seems reasonable: Specialisation is a more modest form of inlining with code size in mind, one that even works for recursive functions. It could chew on stuff the inliner gave up on because of code size requirements (even non-recursive functions). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0