November 2016 - ghc-tickets

[GHC] #9429: Alternative to type family Any
by GHC 18 Feb '18

18 Feb '18

#9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 9097, 9380 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In GHC HEAD, `Any` is no longer a datatype. There are good reasons for this change, one of which was explained in #9097, the original ticket, and another in #9380. Unfortunately, a casualty of this change is that it is no longer easy to generalize the [https://hackage.haskell.org/package/rank1dynamic|rank1dynamic package] to rank-1 types with type variables of arbitrary kind (not just `*`). We submitted a way to do so [here], that exploits the fact that `Any` has the very magical property of inhabiting *all* kinds, including closed ones. This works for GHC 7.8, but won't work in HEAD, because we require that there exists a `Typeable` instance for `Any`, just as there are `Typeable` instances for any other type one wishes to have instances for. The reason is that now that `Any` is a type family, `Any` is no longer a legal instance head. There are several possible solutions that I see: * while it's clearly dangerous for the compiler to be inserting the old `Any` during typechecking from the moment that we have computation in types over closed kinds, we may still want the old `Any`, say under a different name, as a backdoor. It wouldn't be used by the compiler during type checking - only by packages such as rank1dynamic. I believe that furthermore, if we restrict the old `Any` to not inhabit closed kinds, then none of the problems cited in the above tickets arise. * Instead of making the new `Any` a type family, keep it a datatype, but ban it from inhabiting closed kinds. I don't know if such an `Any` would be sufficient for the purposes of GHC, however. * Hardwire a `Typeable` instance for the `Any` type family (not sure if this makes sense). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #8258: GHC accepts `data Foo where` in H2010 mode
by GHC 14 Feb '18

14 Feb '18

#8258: GHC accepts `data Foo where` in H2010 mode --------------------------+------------------------------------------------ Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 7.8.1 Component: | Version: 7.0.4 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts invalid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ According to the Haskell2010 report, The grammar productions relevant for `data` declarations are the following: {{{ topdecl → data [context =>] simpletype [= constrs] [deriving] }}} (from [http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2 4.2.1 Algebraic Datatype Declarations]) However, GHC 7.0.4/7.4.2/7.6.3/HEAD all happily compile the following Haskell module without any warning when using `-XHaskell2010 -Wall`, even though this is not valid Haskell2010 afaik: {{{#!hs module Foo where data Foo where }}} The trailing `where` in the `data` declaration is not valid Haskell2010 (without language extensions such as `GADT`). At the very least, this divergence from the Haskell Report should be mentioned in [http://www.haskell.org/ghc/docs/latest/html/users_guide /bugs-and-infelicities.html#haskell-standards-divergence 14.1.1. Divergence from Haskell 98 and Haskell 2010]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9269: Type families returning quantified types
by GHC 14 Feb '18

14 Feb '18

#9269: Type families returning quantified types ------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: | ------------------------------------+------------------------------------- Is there a fundamental reason for not being able to use quantification in a type family? I'd very much like to be able to do it, obviously turning on RankNTypes if necessary. I'm looking for things like this: {{{#!haskell type family Foo (x :: Bool) where Foo True = forall a. [a] Foo False = () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9269> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12422: Add decidable equality class
by GHC 14 Feb '18

14 Feb '18

#12422: Add decidable equality class -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.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: -------------------------------------+------------------------------------- Currently, we have a `TestEquality` class {{{#!hs class TestEquality f where testEquality :: f a -> f b -> Maybe (a :~: b) }}} It would be nice to add a class for fully decidable equality. There are a few options, but this one gets to the point rather quickly: {{{#!hs data EqDec a b where NotEqual :: (forall c . a :~: b -> c) -> EqDec a b Equal :: EqDec a a class DecEq f where decEq :: f a -> f b -> EqDec a b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12262: Binary output is not deterministic
by GHC 07 Feb '18

07 Feb '18

#12262: Binary output is not deterministic -------------------------------------+------------------------------------- Reporter: niteria | 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: -------------------------------------+------------------------------------- The goal of DeterministicBuilds (#4012) was to get ABI-compatible binaries given the same sources, flags and the environment. There's a stronger goal of getting bit-for-bit identical binaries and this ticket will track that. Known causes of binary nondeterminism: * Unique comparison * Uniques converted to strings for symbol names * everything else from #4012 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12685: getNumProcessors semantics dont match documentation
by GHC 06 Feb '18

06 Feb '18

#12685: getNumProcessors semantics dont match documentation ----------------------------------------+--------------------------------- Reporter: Llgn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Hi, The documentation of getNumProcessors says : "Returns the number of CPUs that the machine has", but it is true only for program compiled with -threaded option. https://hackage.haskell.org/package/base-4.9.0.0/docs/GHC-Conc- Sync.html#v:getNumProcessors I guess the documentation is just misleading. Or is it a bug ? Regards -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix
by GHC 05 Feb '18

05 Feb '18

#8684: hWaitForInput cannot be interrupted by async exceptions on unix ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- http://hackage.haskell.org/package/base-4.6.0.1/docs/System-Timeout.html claims that {{{timeout}}} can interrupt {{{hWaitForInput}}}, but in fact that's false (e.g. mentioned in https://ghc.haskell.org/trac/ghc/ticket/7353#comment:4) {{{ -- import Control.Concurrent import System.IO import System.Timeout main = timeout (1 * 1000000) $ hWaitForInput stdin (5 * 1000) }}} will not be killed after 1 second, but instead wait for the full 5 seconds timeout passed to {{{hWaitForInput}}}. The implementation is {{{ready}}} at http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO- FD.html, where we have two foreign calls: {{{safe fdReady}}} and {{{unsafe unsafe_fdReady}}}. The actual C implementation is at https://github.com/haskell- suite/base/blob/master/cbits/inputReady.c#L16. It uses {{{select}}} on Unix, and does check for {{{EINTR}}}, so I believe that according to http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/ffi.html#ffi- interruptible both foreign calls can be replaced by a single {{{interruptible}}} one. Is that true? If not, it's a documentation bug in {{{timeout}}} at least. Also, does {{{interruptible}}}, apart from allowing the function to be interrupted, behave more like {{{safe}}} or {{{unsafe}}}? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 32

[GHC] #8228: GHC built under Windows does not generate dyn_hi files
by GHC 04 Feb '18

04 Feb '18

#8228: GHC built under Windows does not generate dyn_hi files ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC doesn't work at all Unknown/Multiple | Test Case: cabal01 Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I found cabal01 failing with: {{{ =====> cabal01(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory cabal01 VANILLA=--enable-library- vanilla PROF=--disable-l ibrary-profiling DYN=--enable-shared </dev/null >cabal01.run.stdout 2>cabal01.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: Creating library file: dist\build\libHStest-1.0-ghc7.7.20130904.dll.a setup.exe: Error: Could not find module: A with any suffix: ["dyn_hi"] in the search path: ["dist\\build"] make[2]: *** [cabal01] Error 1 }}} but I bet some of the other failures are due to this. Indeed, in dist/build, there are no dyn_hi files When I look more closely at the commands being run, I see: {{{ bash.exe-3.1$ c:/Users/ezyang/Dev/ghc-validate/inplace/bin/ghc-stage2.exe --make -fbuilding-ca bal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odi r dist/build -hidir dist/build -stubdir dist/build -i -idist/build -i. -idist/build/autogen -I dist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -package- name test-1.0 -hide-all- packages -no-user-package-db -package-db local.db -package-db dist/pac kage.conf.inplace -package-id base-4.7.0.0-inplace -XHaskell98 -XForeignFunctionInterface A B. A -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db [1 of 2] Compiling B.A ( B\A.hs, dist\build\B\A.o ) [2 of 2] Compiling A ( A.hs, dist\build\A.o ) }}} which should result in dyn_hi files but does not. I haven't traced it any further yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8228> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #11706: Increase precedence of statements (if-then-else, case-of, do)
by GHC 03 Feb '18

03 Feb '18

#11706: Increase precedence of statements (if-then-else, case-of, do) -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: ⊥ Component: Compiler | Version: (Parser) | 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: -------------------------------------+------------------------------------- Warning: Skip to the {{{TL; DR}}}, and maybe the {{{How it works}}} section; You don't want to read this. (I've warned you.) == The problem == We do it all the time: Writing that one dollar sign just before our expressions, just because Haskell can't parse it: {{{#!hs f x = g $ if x then {- ... -} else {- ... -} f x = g $ case x of {- ... -} f x = g $ do {- ... -} }}} However, we programmers are lazy and want to type as few characters as possible. Think about the precious characters we would save if we could write code this way: {{{#!hs f x = g if x then {- ... -} else {- ... -} f x = g case x of {- ... -} f x = g do {- ... -} }}} Wow, our productivity just shot up by a whopping 6%! However, this code looks ugly, noone would ever write this... Right? There has to be some way to catagorize this feature with others people would never use... == Pragmas to the rescue! == The {{{LANGUAGE}}} pragma! Of course! We can add a syntactic extension to enable above syntax! But how should we name it... {{{InlineStatements}}}? {{{InfixStatements}}}? {{{ParenthesizedStatements}}}? {{{IncreasedStatementPrecedence}}}? {{{StatementsWithoutParenthesis}}}? I don't know. I am [1] not the parents who might one day give birth to this feature. I am merely the one who conceptualized it. [1] (probably, unless this request remains unnoticed for another 20 years or so) == How it works == * Implicit parenthesis will be put around ''all'' statements, according to the following rules: 1. Parenthesis will be opened at the start of the statement. 2. Parenthesis will be closed at the end of the statement. The end of the statement is determined by 1. The curly brackets around the statement, or; 2. The indentation of the statement Basically, these are the rule Haskell already uses. Sorry if this is obvious, but some people seemed to get confused, so here's some examples: === (Correct) Examples === Examples are in the form: {{{#!hs implicitParenthesis -- New syntax explicitParenthesis -- Old syntax }}} Call {{{idM :: Monad m => m a -> m a}}} as {{{idM :: IO String -> IO String}}}. {{{#!hs idM do putStrLn "What's my name?" getLine idM (do { putStrLn "What's my name?"; getLine; }) }}} Create function {{{whatsMyName :: Maybe String -> String}}}. {{{#!hs whatsMyName x = id case x of Just name = "My name is " ++ name Nothing = "What's my name?" whatsMyName x = id (case x of { Just name = "My name is " ++ name; Nothing = "What's my name?"; }) }}} Another example using {{{let}}} and {{{if-then-else}}}. {{{#!hs main = putStrLn (++) "I've been tryna work it out... The square root of 69 is 8 something, right? " let eight_something = 8.306623862918075 in if sqrt 69 == eight_something then "Yeah" else "Oh na na" main = putStrLn ((++) "I've been tryna work it out... The square root of 69 is 8 something, right? " (let eight_something = 8.306623862918075 in (if sqrt 69 == eight_something then "Yeah" else "Oh na na")) }}} === Incorrect examples === {{{#!hs f do putStrLn "This won't work..." True f (do { putStrLn "This won't work..."; True; }) }}} {{{#!hs f do putStrLn "This won't work..." True -- Indented by extra space f (do { putStrLn "This won't work..."; True; }) }}} == TL; DR == What there is: {{{#!hs main = when $ do putStrLn "Parenthesis..." main = when True (do putStrLn "Parenthesis...") }}} What I want: {{{#!hs when (doBlocksNeedParenthesis) do putStrLn "This code is invalid." when (doBlocksNeedParenthesis) $ do putStrLn "This code is valid." when (doBlocksNeedParenthesis) (do putStrLn "This code is valid aswell.") when (thisIsImplemented) do putStrLn "These are all equal" when (thisIsImplemented) (do putStrLn "These are all equal") when (thisIsImplemented) $ do putStrLn "These are all equal" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11195: New pattern-match check can be non-performant
by GHC 01 Feb '18

01 Feb '18

#11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- In my work in merging Phab:D808 (and originally pointed out by thomie), I ran into a peculiar bug: the new pattern-match check took gobs of memory (~10GB) to check !OptCoercion in the stage-2 compiler. My analysis got only as far as nailing the problem down to `pmTraverse`, which took 80% of the time, and got called roughly a gajillion times. To reproduce, simply compile !OptCoercion (with `-package ghc`) and you'll see your memory usage explode. So that you'll be able to build GHC until this is fixed, I've disable the pattern-match check in that file. There is a good chance that this is caused by an interaction between the pattern-match check and the type=kind code. I'm happy to probe further, but I'd want George's help. NB: This applies only after my patch is merged. Which should be today. For some value of today. Hopefully today's value of today. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21