August 2016 - ghc-tickets

[GHC] #10963: Beginner-targeted language extension
by GHC 29 Aug '16

29 Aug '16

#10963: Beginner-targeted language extension -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- FMP significantly complicated type signatures such as `length :: Foldable t => t a -> Int`, which makes teaching Haskell more difficult. I propose a language extension `-XBeginner` which instructs GHC(i) to specialize `Foldable` and `Traversable` to `[]` when possible and in case of an ambiguous instance, default those to `[]`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10963> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #12530: Template Haskell support for TypeApplications
by GHC 29 Aug '16

29 Aug '16

#12530: Template Haskell support for TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Template | Version: 8.0.1 Haskell | 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: -------------------------------------+------------------------------------- One more TH trick I'd like to have up my sleeve. Patch coming soon. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12530> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1168: Optimisation sometimes decreases sharing in IO code
by GHC 29 Aug '16

29 Aug '16

#1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | nofib/spectral/calendar Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1168#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2.
by GHC 29 Aug '16

29 Aug '16

#5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: akio Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2486 Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * owner: daniel.is.fischer => akio * differential: => Phab:D2486 Comment: I implemented rules for `div` and `mod`. I decided not to do anything with Euclidean division because (1) the rules I added are valid for the current semantics (floor division) as well as for Euclidean division, and (2) I believe that changing the semantics of `div` and `mod` is a much bigger change and should be discussed separately. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5615#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4239: -ddump-minimal-imports vs. type operators
by GHC 28 Aug '16

28 Aug '16

#4239: -ddump-minimal-imports vs. type operators -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T4239 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2480 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D2480 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4239#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12029: Notify user to import * from Data.Kind with TypeInType on
by GHC 28 Aug '16

28 Aug '16

#12029: Notify user to import * from Data.Kind with TypeInType on -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: GHCi | Version: 8.1 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: -------------------------------------+------------------------------------- With `TypeInType` asking for the kind of `*` gives the user a warning to import it {{{ ghci> :set -XTypeInType ghci> :k * <interactive>:1:1: error: Not in scope: type constructor or class ‘*’ NB: With TypeInType, you must import * from Data.Kind <interactive>:1:1: error: Illegal operator ‘*’ in type ‘*’ Use TypeOperators to allow operators in types <interactive>:1:1: error: Operator applied to too few arguments: * }}} Should a similar warning be issued when she asks for information on it {{{ ghci> :i * class Num a where ... (*) :: a -> a -> a ... -- Defined in ‘GHC.Num’ infixl 7 * }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12029> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12368: Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation
by GHC 28 Aug '16

28 Aug '16

#12368: Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | 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: -------------------------------------+------------------------------------- Not sure how relevant this is, but when reading both paper and code long enough, on inevitably finds some code smell. This is about nested recursion, as in this example {{{ f [] = [] f (x:xs) = let g [] = f xs g (y:ys) = y+1 : g ys in g (h x) }}} The “cunning plan” of fixpoint iteration (see Note [Initialising strictness]) says that in the first time an inner recursive definition is looked at, its strictness is assumed to be `b` (`botSig`), and from then on, its `idInformation` (presumably from the previous iteration or the outer recursive definition) is used. A flag (`virgin`) in the analysis environment is used to detect that. The problem is that the fixpoint iteration code in `dmdFix` aborts after more than 10 iterations: {{{ loop' n env pairs | found_fixpoint = (env', lazy_fv, pairs') | n >= 10 = (env, lazy_fv, orig_pairs) -- Safe output }}} This means that if the iteration does not terminate, we will “not” attach a strictness signature to the inner binders (`g` in the example above), but rather leave the binders untouched. Then, in the second iteration of finding a fixpoint for `f`, the `virgin` flag is `False`, and `idStrictness` is used, which in this case will simply be the default, namely `nopSig`. I could not produce an example where it matters. And it might be that it simply does not matter, so I’m not sure what to do with this information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12368> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #12435: Turn "No alternatives for a case scrutinee not known to diverge for sure" into a warning
by GHC 28 Aug '16

28 Aug '16

#12435: Turn "No alternatives for a case scrutinee not known to diverge for sure" into a warning -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- This was discussed in the context of #10180, #11290 and Phab:D851; let’s focus on this here. In changeset:a0678f1f0e62496c108491e1c80d5eef3936474a/ghc we introduced a lint ''error'' that would abort compilation if there is an empty case with a scrutinee not known to diverge for sure. It is then nature of such a test that it is never complete (we’d solve the halting problem). Occasionally, when working on other parts of the code, together with other transformations (such as CSE), we get Core code that does not pass the test, even though the scrutinee ''is'' diverging. Whenever it occurs, we have to find out why needs to be done to make the test pass again, e.g. by ensuring that CSE cse’s things in the right order, or whatnot. This slows down development (e.g. I cannot test my work on #12368 on the auto-builders because of this). It feels wrong to me to give a necessarily non-complete test such a high priority. I therefore propose to turn this check into a lint ''warning''. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12116: No easy way to add cost-centre to top-levels
by GHC 27 Aug '16

27 Aug '16

#12116: No easy way to add cost-centre to top-levels -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- As far as I can see from the user manual (I also tried placing some `SCC`s), there's no way to easily add cost-centres to top-level definitions. We can do things like: {{{ f x y z = ... => f = {-# SCC f #-} \x y z -> ... }}} but it becomes too much work once we have "equations" style definitions like {{{ head [] = {-# SCC head #-} Nothing head (x : _) = {-# SCC head #-} Just x }}} Also, `where` clauses work differently after the transformations. Example: {{{ f x y z = ... where <can use x and y here> => f = {-# SCC f #-} \x y z -> ... where <can't use x and y here> }}} So it gets annoying real quick. It'd be really great if we could just add `{-# SCC ... #-}` just like `{-# INLINE ... #-}` pragmas. Any ideas/opinions? Looking at the code, it seems like `-fprof-auto` and similar flags are adding ticks to `FunBind.fun_tick`. We could do the same with this new `SCC` pragma. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12516: Preprocessing: no way to portably use stringize and string concatenation
by GHC 27 Aug '16

27 Aug '16

#12516: Preprocessing: no way to portably use stringize and string concatenation -------------------------------------+------------------------------------- Reporter: harendra | Owner: 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: -------------------------------------+------------------------------------- To reduce boilerplate code in an FFI implementation file I am trying to use the stringizing and string concatenation features of the C preprocessor. But it seems there is no portable way to do that. I am listing what I tried below: 1. Using stringizing and string concatenation in traditional mode (https://gcc.gnu.org/onlinedocs/cpp/Traditional-macros.html) ghc uses cpp in traditional mode by passing `-traditional`. The behavior of `-traditional` mode is not consistent across gcc and clang. While gnu cpp supports stringizing and string concatenation in traditional mode clang cpp does not support it. 2. Disable traditional mode on the given file. There is no way to disable `-traditional` via `-optP` since it only appends new options to the preprocessor and does not override the old ones. 3. There is an issue in using the clang cpp via `-pgmP cpp`. clang cpp does not accept a space between `-I` flag and the include directory. For example `cpp -I .` fails with `clang: error: no such file or directory: 'c'`. ghc passes this flag with a space. 4. Finally, using cc as a preprocessor worked for me: `{-# OPTIONS_GHC -pgmP cc -optP -E -optP -undef -optP -std=c89 #-}`. But This relies on cc being in `PATH` and always pointing to a compiler which behaves in the way we want. In theory, cc may turn out to be different than the compiler and preprocessor actually used by ghc. But this still seems to be the best practical option and I am using this one. Possible solutions could be: * Use a native preprocessor, something like `cpphs`. * A temporary workaround could be to provide a way to override the preprocessor options (rather than appending to them) so that we can knowingly use the configured ghc preprocessor program without the traditional flag, something like `-optP--override`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2