April 2018 - ghc-tickets

[GHC] #14955: Musings on manual type class desugaring
by GHC 27 Apr '18

27 Apr '18

#14955: Musings on manual type class desugaring -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: SpecConstr | 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 recently wrote a short post explaining why manual type class desugaring was different to actually writing a type class because of how they are optimised. http://mpickering.github.io/posts/2018-03-20-recordsvstypeclasses.html I implement 4 different equivalent programs which are all optimised differently. I paste the whole file below as it is not very big. Implementation 1 is in terms of a type class. Implementation 2 is in terms of explicit dictionary passing. Implementation 3 wraps a dictionary in a type class Implementation 4 wraps a dictionary in a type class with an additional dummy argument. Naively, a user would expect all 4 implementations to be as fast as each other. {{{ {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE AllowAmbiguousTypes #-} module Prop where import Prelude (Bool(..), (||), (&&)) -- Implementation 1 class Prop r where or :: r -> r -> r and :: r -> r -> r true :: r false :: r instance Prop Bool where or = (||) and = (&&) true = True false = False -- Implementation 2 data PropDict r = PropDict { dor :: r -> r -> r , dand :: r -> r -> r , dtrue :: r , dfalse :: r } boolDict = PropDict { dor = (||) , dand = (&&) , dtrue = True , dfalse = False } -- Implementation 3 class PropProxy r where propDict :: PropDict r instance PropProxy Bool where propDict = boolDict -- Implementation 4 class PropProxy2 r where propDict2 :: PropDict r dummy :: () instance PropProxy2 Bool where propDict2 = boolDict dummy = () ors :: Prop r => [r] -> r ors [] = true ors (o:os) = o `or` ors os {-# INLINABLE ors #-} dors :: PropDict r -> [r] -> r dors pd [] = dtrue pd dors pd (o:os) = dor pd o (dors pd os) pors :: PropProxy r => [r] -> r pors [] = dtrue propDict pors (o:os) = dor propDict o (pors os) {-# INLINABLE pors #-} porsProxy :: PropProxy2 r => [r] -> r porsProxy [] = dtrue propDict2 porsProxy (o:os) = dor propDict2 o (porsProxy os) {-# INLINABLE porsProxy #-} }}} Then using the 4 different implementations of `ors` in another module implementations 1 and 4 are fast whilst 2 and 3 are slow. https://github.com/mpickering/rtcwrao-benchmarks/blob/master/Prop2.hs {{{ benchmarking tc/Implementation 1 time 3.510 ms (3.509 ms .. 3.512 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 2.976 ms (2.886 ms .. 3.060 ms) std dev 241.1 μs (195.4 μs .. 293.1 μs) variance introduced by outliers: 51% (severely inflated) benchmarking tc/Implementation 2 time 25.05 ms (21.16 ms .. 30.43 ms) 0.912 R² (0.849 R² .. 0.984 R²) mean 19.18 ms (16.20 ms .. 21.45 ms) std dev 5.627 ms (4.710 ms .. 6.618 ms) variance introduced by outliers: 89% (severely inflated) benchmarking tc/Implementation 3 time 20.06 ms (15.33 ms .. 23.57 ms) 0.856 R² (0.755 R² .. 0.934 R²) mean 18.43 ms (16.92 ms .. 19.85 ms) std dev 3.490 ms (3.003 ms .. 4.076 ms) variance introduced by outliers: 74% (severely inflated) benchmarking tc/Implementation 4 time 3.498 ms (3.484 ms .. 3.513 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 3.016 ms (2.935 ms .. 3.083 ms) std dev 205.7 μs (162.6 μs .. 261.8 μs) variance introduced by outliers: 42% (moderately inflated) }}} I compiled the module with `-O2`. If I turn off `-fno-worker-wrapper` and `-fno-spec-constr` then implementation 3 is also fast. Implementation 2 is always slow. This ticket is querying what could be done to improve the robustness of these different refactorings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15092: Optionally bounds-check primops
by GHC 27 Apr '18

27 Apr '18

#15092: Optionally bounds-check primops -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | 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: -------------------------------------+------------------------------------- It would be awfully nice if there were a way to optionally get bounds- checked versions of array primitives. The idea would be that if GHC is compiled with a bounds-checking option, then the code generator would use primops that verify indices are in bounds. Based on [https://mail.haskell.org/pipermail/haskell-cafe/2018-April/128992.html a question by Henning Thielemann], I suspect such a feature would get some use. The biggest challenge: `SomeException`, `Typeable`, `Show`, `String`, `CallStack`, etc., all live in an entirely different universe than the primops, so it's not exactly obvious how to get started. I don't know if it would be possible to inject references to such things into a lower level. Sounds hard, but maybe it's possible. An alternative, probably much simpler, approach would be to crash hard with an error message instead of trying to throw a proper exception. Ideally, the error message would include the name of the primop and (for modules compiled with profiling) some call stack info. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14421: LambdaCase should be suggested if it is used but not enabled
by GHC 27 Apr '18

27 Apr '18

#14421: LambdaCase should be suggested if it is used but not enabled -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | 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: -------------------------------------+------------------------------------- If I try to make a multiparameter typeclass GHC (well, GHCi here) advises me to turn on {{{MultiParamTypeClasses}}} {{{ Prelude> class C a b where ... (Use MultiParamTypeClasses to allow multi-parameter classes) }}} But if I try to use {{{\case}}} it doesn't give me a helpful suggestion {{{ Prelude> :t \case (_,_) -> () <interactive>:1:2: error: parse error on input ‘case’ }}} Could it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13520: instance Alternative ZipList
by GHC 27 Apr '18

27 Apr '18

#13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- The paper "From monoids to near-semirings: the essence of MonadPlus and Alternative`" mentions > Perhaps surprisingly, `ZipList`s have an `Alternative` instance. Like the `Alternative` instance for `Maybe`, the one for `ZipList` has a left bias. > > {{{#!hs > instance Alternative ZipList where > empty :: ZipList a > empty = ZL [] > > (<|>) :: ZipList a -> ZipList a -> ZipList a > ZL xs <|> ZL ys = ZL (xs ++ drop (length xs) ys) > }}} Has this been considered for base? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13876: Check 'pure' method of 'Applicative (WrappedMonad m)'
by GHC 26 Apr '18

26 Apr '18

#13876: Check 'pure' method of 'Applicative (WrappedMonad m)' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: -------------------------------------+------------------------------------- Should {{{#!hs instance Monad m => Applicative (WrappedMonad m) where pure = WrapMonad . pure WrapMonad f <*> WrapMonad v = WrapMonad (f `ap` v) }}} not use `return`? {{{#!hs instance Monad m => Applicative (WrappedMonad m) where pure = WrapMonad . return WrapMonad f <*> WrapMonad v = WrapMonad (f `ap` v) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13876> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14200: Deprecate WrappedMonad
by GHC 26 Apr '18

26 Apr '18

#14200: Deprecate WrappedMonad -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 libraries/base | 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 believe that `Control.Applicative.WrappedMonad` is obsolete now that AMP is implemented. I would propose deprecating `WrappedMonad` as a result. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14200> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15027: Remove WrappedMonad from Control.Applicative
by GHC 26 Apr '18

26 Apr '18

#15027: Remove WrappedMonad from Control.Applicative -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: base | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a data type `WrappedMonad` in `Control.Applicative`. It provides an `Applicative` instance for a type based on the `Monad` instance. This type hasn't been useful since AMP landed in GHC 7.10 about three years ago. I propose that this type be marked deprecated in GHC 8.6 and then removed in GHC 8.8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15027> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15028: Deprecate and Remove Data.Semigroup.Option
by GHC 26 Apr '18

26 Apr '18

#15028: Deprecate and Remove Data.Semigroup.Option -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: base | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since the Semigroup-Monoid Proposal has landed, the data type `Option` from `Data.Semigroup` is now obsolete. I propose that it be marked deprecated in GHC 8.6 and removed in GHC 8.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15028> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8406: Invalid object in isRetainer() or Segfault
by GHC 26 Apr '18

26 Apr '18

#8406: Invalid object in isRetainer() or Segfault ----------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- When compiling with -rtsopts -threaded -prof -fprof-auto -caf-all and running with -N4 -hr I get a "Segmentation fault" every time. If I run with -N4 -qg1 -hr, I either get a segfault or internal error: Invalid object in isRetainer(): 40 When the segfault happens, it happens quickly. If the segfault doesn't happen, the program runs for about 5 seconds and I get "invalid object" error (always 40). Without -hr, I have never gotten a segfault. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8406> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples
by GHC 26 Apr '18

26 Apr '18

#14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.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: -------------------------------------+------------------------------------- It seems that it should be okay to `unsafeCoerce` between types that wrap certain things in unboxed unary tuples and ones that do not. For example, {{{#!hs unsafeCoerce :: (A -> B) -> A -> (# B #) unsafeCoerce :: ((# A #) -> B) -> A -> B }}} Generally, I believe `unsafeCoerce :: E1 -> E2` should be okay when the only differences are in what is wrapped in an unboxed unary tuple and both of the following hold: 1. Each new unary tuple wrapper in `E2` is in a positive position. 2. Each new unary tuple wrapper in `E1` is in a negative position. Semantically, {{{#!hs unsafeCoerce :: (A -> B) -> A -> (# B #) = \f a -> let !fa = f a in (# fa #) unsafeCoerce :: ((# A #) -> B) -> A -> B = \f !a -> f a }}} Am I correct in this interpretation? If so, is this something the developers would be willing to commit to and document? The first version in particular (a new unary tuple wrapper in positive position in the result) would be very useful for reducing both source code and generated code size in libraries supporting both strict and lazy operations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14806> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4