- ghc-tickets - Haskell.org

[GHC] #9251: ghc does not expose brancheless max/min operations as primops
by GHC 21 Jan '19

21 Jan '19

#9251: ghc does not expose brancheless max/min operations as primops ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | ------------------------------------+------------------------------------- It was pointed out in #9246 that GHC currently does not expose primops for Max and Min on various unlifted types such as Float# and Double# and Int# and Word#, but that on most modern CPU architectures there is instruction level support for these operations. (Eg, Float# and #Double min and max can be provided on any 64bit x86 system pretty easily ) This ticket is to track doing that task. I'll probably do it one of the next two weekends to get back in the GHC hacking groove, or maybe this should be used as a "getting started" ticket for a new contributor? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #16211: Recompiling results in a missing instance
by GHC 21 Jan '19

21 Jan '19

#16211: Recompiling results in a missing instance -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached program compiles without error using cabal. {{{ import Bar main :: IO () main = do let x = True -- line 5 --x <- True -- line 6 foo x bar foo :: Bool -> IO () -> IO () foo _ _ = undefined }}} However: 1. `cabal build`. This succeeds. [This step isn't required to reproduce the bug, but it shows that the program should compile.] 2. Replace line 5 with line 6 in Main.hs 3. `cabal build`. GHC correctly reports a compile error (`Couldn't match expected type 'IO Bool' with actual type 'Bool'`) 4. Fix the problem by reinstating line 5 and removing line 6. 5. `cabal build`. This step *should* compile without errors, but instead I get a GHC error about a missing instance related to the `monad-classes` library. 6. `cabal build` all day. The `missing instance` error still occurs until you clean temporary files and start from scratch. I suspect the error in step 5 is itself a (different?) GHC bug, but for now it is reported [https://github.com/strake/monad-classes.hs/issues/4 here]. This GHC bug report is specifically about compiling with identical source code (steps 1 and 5) and getting different outcomes (step 1 compiles, step 5 has an error), which shouldn't happen regardless of other bugs. [Note I can produce the `missing instance` issue without having to recompile GHC, which is why I think it might be independent of this bug.] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16211> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs
by GHC 21 Jan '19

21 Jan '19

#2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: thoughtpolice Type: task | Status: new Priority: low | Milestone: 8.10.1 Component: Compiler (NCG) | Version: 6.11 Resolution: | Keywords: codegen 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 bgamari): > Maybe we should revisit? It sounds like we should. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14670: -XRebindableSyntax needs return?
by GHC 21 Jan '19

21 Jan '19

#14670: -XRebindableSyntax needs return? -------------------------------------+------------------------------------- Reporter: jackkelly | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple RebindableSyntax | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documentation for -XRebindableSyntax ( https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #rebindable-syntax-and-the-implicit-prelude-import ) reads: > “Do” notation is translated using whatever functions (>>=), (>>), and fail, are in scope (not the Prelude versions). List comprehensions, mdo (The recursive do-notation), and parallel array comprehensions, are unaffected. The following code fails to compile (also confirmed to fail on GHC 8.0.2): {{{ {-# LANGUAGE RebindableSyntax #-} module Lib where import Prelude (IO) foo :: IO () foo = do pure () }}} It fails with this error: {{{ /home/kel317/z/src/Lib.hs:9:3: error: Not in scope: ‘return’ Perhaps you want to add ‘return’ to the import list in the import of ‘Prelude’ (src/Lib.hs:5:1-19). | 9 | pure () | ^^^^^^^ }}} To my reading, either something funky is going on with the way the do- notation is desugared, or the documentation needs to be corrected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14670> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #16123: QuantifiedConstraints fails to deduce trivial constraint
by GHC 21 Jan '19

21 Jan '19

#16123: QuantifiedConstraints fails to deduce trivial constraint -------------------------------------+------------------------------------- Reporter: eschnett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While experimenting with quantified constraints, I find I need to explicitly specify a quantified constraint in an instance declaration that I think should be deduced automatically. When I leave it out, GHC complains that it cannot deduce {{{Num (f a)}}} in the code below. The full source code is attached. The relevant lines are {{{ instance ( Functor f, Dom f ~ NFun, Cod f ~ NFun , forall a. Ok NFun a => Num a -- I don't want to write this constraint ) => Functor (NIdF f) where type Dom (NIdF f) = Dom f type Cod (NIdF f) = Cod f fmap f = NFun \(NIdF xs) -> NIdF (neval (fmap f) xs) }}} where the line marked "I don't want to write ..." points to the constraint I don't want to have to write manually. The definition of the {{{NFun}}} is {{{ instance Category NFun where type Ok NFun a = Num a id = NFun P.id NFun g . NFun f = NFun (g P.. f) }}} Note that the constraint in question does not involve the type {{{NIdF}}} for which the instance is declared – it is a generic condition that is always true, given the instance declaration of {{{NFun}}} (see the definition of {{{Ok}}} there). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs
by GHC 21 Jan '19

21 Jan '19

#2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: thoughtpolice Type: task | Status: new Priority: low | Milestone: 8.10.1 Component: Compiler (NCG) | Version: 6.11 Resolution: | Keywords: codegen 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 hsyl20): > I have just (2015/03/03) written a shell script (attached) that tests for binutils support for 64 bit pc-relative relocatons. > The test passes on *all* modern linux systems, but fails on Mac OSX (Mavericks) and OpenBSD 5.5 (current is 5.6). The failure is one OpenBSD says: According to https://www.openbsd.org/58.html, since OpenBSD 5.8 (2015-10-18), binutils have been upgraded to 2.17. > OSX has the linker from LLVM which theoretically could be fixed. LLD handles them since 2015-02-24 (https://reviews.llvm.org/rL230465) First release containing the patch: 3.7 (2015-09-01). Maybe we should revisit? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
by GHC 21 Jan '19

21 Jan '19

#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Would it be possible to generate the hs-boot file (or some equivalent) as a by-product of a module dependency analysis? E.g. {{{ module A where import B data Flip = MkFlip Flop flip :: Int -> Flip flip _ = MkFlip (flop []) module B where import A data Flop = MkFlop Flip flop :: [a] -> Flop flop _ = MkFlop (flip 42) }}} Dependency analysis based just on names finds out that `B` uses `A(Flip, flip)` and `A` uses `B(Flop, flop)`. The compiler could then pick one of (see below) the two modules and generate the hs-boot file: {{{ module A where data Flip flip :: Int -> Flip }}} This has the advantage of keeping the current model of separate compilation instead of starting to merge huge SCCs of the dependency graph into one module that takes eons to compile. I'm not sure if Haskell projects would be affected by the same trend, but large Java projects tend to have SCCs comprised of [https://link.springer.com/article/10.1007/s10664-006-9033-1 hundreds, if not thousands of files]. Of course, I just hand-waved over many technical challenges in my proposal above. I'm pretty certain the above approach would need actual involvement from the type-checker in complicated cases. I don't dare to think about handling type families this way, but wouldn't a name resolution approach get rid of 90% of the cases where we would need hs-boot files? Note that the compiler can still yell at you if it doesn't find a proper solution, or a solution that would involve the type-checker. Imagine that we didn't provide a type signature for `flip` or for `flop`. The above idea would not be able to synthesize the boot file for either `A` or `B`, because it doesn't do actual type-checking across modules. I imagine an error like: {{{ Couldn't infer any type of recursive group {A.flip, B.flop} Provide type signatures or an hs-boot file for any of the occuring modules to fix this. }}} Note that if we only leave out the type signature of `flip`, we still have enough information to compute the hs-boot file for `B` instead of `A`. In general, deciding which module to generate the boot file for could take other criteria, like minimality, into account. We could also have a look at how the D language does things, which has both strong meta-programming capabilities and allows circular module dependencies. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1409#comment:79> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
by GHC 21 Jan '19

21 Jan '19

#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by explicitcall): * cc: explicitcall@… (removed) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1409#comment:78> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
by GHC 21 Jan '19

21 Jan '19

#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1409#comment:77> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16173: Move `Data.Profunctor` from `profunctors` package to `base`
by GHC 21 Jan '19

21 Jan '19

#16173: Move `Data.Profunctor` from `profunctors` package to `base` -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.6.3 Libraries | Keywords: base, | Operating System: Unknown/Multiple profunctor, QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14767 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `Contravariant` was added in GHC 8.6. * https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Functor- Contravariant.html `Profunctor` also looks like fundamental abstraction to be worth considering adding to `base`. Having both `Profunctor` and `Choice` typeclasses in the `base` library will also allow to write `microprism` package similar to `microlens`. Prisms often turns to be very useful since they allow to work nicely with sum types. {{{#!hs type Prism s t a b = forall p f. (Choice p, Applicative f) => p a (f b) -> p s (f t) }}} Additional context for this ticket from Reddit: * https://www.reddit.com/r/haskell/comments/8v53cb/announce_ghc_861alpha1_ava… It was proposed on Reddit to use `QuantifiedConstraints` for `Profunctor`. I'm not quite fluent with `QuantifiedConstraints`, but I think this may looks like this (mostly copy-pasting code from `profunctors` package): {{{#!hs {-# LANGUAGE QuantifiedConstraints #-} class (forall a . Functor (p a)) => Profunctor p where {-# MINIMAL dimap | (lmap, rmap) #-} dimap :: (a -> b) -> (c -> d) -> p b c -> p a d dimap f g = lmap f . rmap g lmap :: (a -> b) -> p b c -> p a c lmap f = dimap f id rmap :: (b -> c) -> p a b -> p a c rmap = dimap id instance Profunctor (->) where dimap ab cd bc = cd . bc . ab lmap = flip (.) rmap = (.) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16173> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4