- ghc-tickets - Haskell.org

[GHC] #14387: listToMaybe doesn't participate in foldr/build fusion
by GHC 26 Oct '17

26 Oct '17

#14387: listToMaybe doesn't participate in foldr/build fusion -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.2.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: -------------------------------------+------------------------------------- I noticed that `Data.OldList.findIndex` seems to use more memory than necessary, and that changing the definition of `listToMaybe` to be in terms of `foldr` fixed the situation. Consider the following module: {{{ {-# LANGUAGE MagicHash #-} {-# OPTIONS_GHC -ddump-to-file -ddump-prep -O #-} module FindIndex where import GHC.Base (Int(I#), build) import GHC.Prim -- | The definitions of listToMaybe, findIndices and findIndex are taken from base listToMaybe :: [a] -> Maybe a listToMaybe [] = Nothing listToMaybe (a:_) = Just a findIndices :: (a -> Bool) -> [a] -> [Int] findIndices p ls = build $ \c n -> let go x r k | p x = I# k `c` r (k +# 1#) | otherwise = r (k +# 1#) in foldr go (\_ -> n) ls 0# {-# inline findIndices #-} findIndex :: (a -> Bool) -> [a] -> Maybe Int findIndex p = listToMaybe . findIndices p -- This is the definition of findIndices when USE_REPORT_PRELUDE is defined findIndices' :: (a -> Bool) -> [a] -> [Int] findIndices' p xs = [ i | (x,i) <- zip xs [0..], p x] {-# inline findIndices' #-} listToMaybe' :: [a] -> Maybe a listToMaybe' = foldr (const . Just) Nothing -- | using listToMaybe', we get a join point findIndex2 :: (a -> Bool) -> [a] -> Maybe Int findIndex2 p = listToMaybe' . findIndices p -- | a "manual" implementaiton, we get a join point findIndex3 :: (a -> Bool) -> [a] -> Maybe Int findIndex3 p = go . zip [0..] where go [] = Nothing go ((i, x) : xs) | p x = Just i | otherwise = go xs -- | alternate version of findIndices, stock listToMaybe, no join point findIndex4 :: (a -> Bool) -> [a] -> Maybe Int findIndex4 p = listToMaybe . findIndices' p -- | alternate version of findIndices, foldr listToMaybe, we get a join point findIndex5 :: (a -> Bool) -> [a] -> Maybe Int findIndex5 p = listToMaybe' . findIndices' p }}} Find attached .dump-prep files with ghc-8.2.1 and ghc-head at commit 5c178012f47420b5dfa417be21146ca82959d273. My interpretation of this is: with both ghc-8.2.1 and ghc-head, findIndex{2,4,5} get join points and findIndex{"",3} don't. Having a join point means constant stack space, not having a join point means linear stack space. I don't understand the simplifier well enough to know whether ghc could do better here, but it seems that changing the definition of `listToMaybe` to {{{ listToMaybe :: [a] -> Maybe a listToMaybe = foldr (const . Just) Nothing }}} would be a win. Are there any downsides? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14387> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7169: Warning for incomplete record field label used as function
by GHC 26 Oct '17

26 Oct '17

#7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: nakaji_dayo Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Warnings, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4083 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:27 Ben Gamari <ben@…>]: > {{{ > Warning on declaring a partial record selector. > However, disable warn with field names that start with underscore. > > }}} Eek. I may be too late. Don't the lenses people use underscore prefix on record labels? So that TH can detect that and produce a lens name with the `_` stripped off? Then they're going to miss out on this warning of partiality. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7169: Warning for incomplete record field label used as function
by GHC 25 Oct '17

25 Oct '17

#7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: nakaji_dayo Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Warnings, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4083 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13986: TypeApplications causes parse errors in @-patterns with certain Unicode characters
by GHC 25 Oct '17

25 Oct '17

#13986: TypeApplications causes parse errors in @-patterns with certain Unicode characters -------------------------------------+------------------------------------- Reporter: Tikhon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following function definition works without TypeApplications but fails to parse with the extension enabled: {{{#!hs {-# LANGUAGE TypeApplications #-} module Mininal where foo x₁@True = 10 }}} It also parses correctly with "x" in place of "x₁". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13986> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14214: Users guide lies about default optimization level
by GHC 25 Oct '17

25 Oct '17

#14214: Users guide lies about default optimization level -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #14208 points out that the users guide claims that the default optimization level is `-O0`. However this apparently isn't true. We should decide whether this should be the default and, if so, identify and fix the differences. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7169: Warning for incomplete record field label used as function
by GHC 25 Oct '17

25 Oct '17

#7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: nakaji_dayo Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4083 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"f7f270eb6ba616feda79d370336db7e66f9ab79c/ghc" f7f270e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f7f270eb6ba616feda79d370336db7e66f9ab79c" Implement `-Wpartial-fields` warning (#7169) Warning on declaring a partial record selector. However, disable warn with field names that start with underscore. Test Plan: Added 1 test case. Reviewers: austin, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: goldfire, simonpj, duog, rwbarton, thomie GHC Trac Issues: #7169 Differential Revision: https://phabricator.haskell.org/D4083 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13707: xmobar crashes with segmentation faults?
by GHC 25 Oct '17

25 Oct '17

#13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Markus Trippelsdorf on `ghc-devs` reports that 8.2.1-rc2 produces crashing `xmobar` executables. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #14384: real numbers, digits after the decimal point - digits of precision
by GHC 24 Oct '17

24 Oct '17

#14384: real numbers, digits after the decimal point - digits of precision -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- the results from computation should have eleven digits after the decimal point for real numbers. (11 digits of precision) it seems reasonable.\\ instead of: {{{ Prelude> (16.0/0.00002)**2.1 2.491661103847512e12 }}} this is better:\\ {{{ 2.49166110385e12 }}} it should be noted that a lot of computing system uses this precision. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14384> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14380: Compile error for PatternSynonyms together with OverloadedLists
by GHC 24 Oct '17

24 Oct '17

#14380: Compile error for PatternSynonyms together with OverloadedLists -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE OverloadedLists #-} {-# LANGUAGE PatternSynonyms #-} data Foo = Foo [Int] pattern Bar :: Foo pattern Bar = Foo [] }}} This code results in a cryptic compilation error: {{{ $ ghc main.hs [1 of 1] Compiling Main ( main.hs, main.o ) main.hs:7:19: error: • Couldn't match expected type ‘[a0] -> [Int]’ with actual type ‘[GHC.Exts.Item Int]’ • This rebindable syntax expects a function with two arguments, but its type ‘Int -> [GHC.Exts.Item Int]’ has only one In the first argument of ‘Foo’, namely ‘[]’ In the expression: Foo [] | 7 | pattern Bar = Foo [] | ^^ }}} As soon as `OverloadedLists` is removed, this error goes away. In itself the problem isn't too critical, but very unexpected. I got above error with GHC 8.0 and 8.2, so decided to check it with current version as well: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.3.20171020 }}} Looking a bit more into `PatternSynonyms` extension I was able to work around this by declaring an explicit bidirectional pattern, which, surprisingly, solved the problem: {{{#!hs pattern Bar :: Foo pattern Bar <- Foo [] where Bar = Foo [] }}} If fixing this issue is too much trouble than it is worth, than at least a mention about it in documentation will be helpful. Out of curiosity I also tried it with `String`, which did not trigger this error and compiled just fine: {{{#!hs {-# LANGUAGE OverloadedLists #-} {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE PatternSynonyms #-} data Foo = Foo [Char] pattern Bar :: Foo pattern Bar = Foo "" }}} PS. Even if this issue is closed, searching the internet for the error message will now at least return some info. :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14383: Allocation in VS up 500%
by GHC 23 Oct '17

23 Oct '17

#14383: Allocation in VS up 500% -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- Somewhere in between the commits fee253fc and 99c61e22 nofib’s `VS` benchmark has allocations increased by 500%. perf.haskell.org is currently defuct (linker errors due to recent changes to the ffi stuff, I believe Moritz is trying to find that out), so I cannot just look there to see which commit broke it. But maybe someone feels like bisecting this. If not maybe perf.haskell.org will be able to tell us once its fixed (although keeping up with GHC commits there is a bit of a pain these days.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3