- ghc-tickets - Haskell.org

Re: [GHC] #6087: Join points need strictness analysis
by GHC 03 Feb '18

03 Feb '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by osa1): In mate with `-flate-dmd-anal` we get lots of new worker functions and the final program is quite different than the one without `-flate-dmd-anal`. I couldn't find yet what's causing the extra allocations as the changes are so big. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #14631: GHC 8.2.2 crashes when building the haskell-gi sample code
by GHC 02 Feb '18

02 Feb '18

#14631: GHC 8.2.2 crashes when building the haskell-gi sample code -------------------------------------+------------------------------------- Reporter: muscar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.2.2 crashes while building the haskell-gi sample code in a new project created with stack (see the attached project). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14736: unknown opcode in interpretBCO doesn't cause process termination in some circumstances
by GHC 02 Feb '18

02 Feb '18

#14736: unknown opcode in interpretBCO doesn't cause process termination in some circumstances ----------------------------------------+--------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- As part of my work on #14675, I ended up in a situation where `rts/Interpreter.c:interpretBCO` falls into its default case, which just does this: {{{#!c barf("interpretBCO: unknown or unimplemented opcode %d", (int)(bci & 0xFF)); }}} Which is fine. In the program from #14675, we are not processing the annotations with an external interpreter, the same runtime is compiling some module and running some code for the annotations, if my understanding is correct. And that process should therefore terminate. Except that it doesn't, not right away! And the example that uses the GHC API to load some simple module with an annotation just happily proceeds until it segfaults because `interpretBCO` didn't run to completion, probably therefore not pushing a suitable closure address or two somewhere or something along those lines. The expected behaviour here would be that the program crashes with the "unknown opcode" error message from above. So far the problem from #14675 has only been reproduced on ubuntu 16.04 with 8.4.1 alpha1, however I suspect that the bug I'm describing -- the program not terminating when we call `barf` while running code that we will splice in some module that we are compiling using the GHC API -- is independent of the particular distro or maybe even OS? Not sure, I haven't looked into that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14753: Assembly for stg_enter_info starts with a dead 'mov'
by GHC 02 Feb '18

02 Feb '18

#14753: Assembly for stg_enter_info starts with a dead 'mov' -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.4.1-alpha1 (CodeGen) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the course of my investigation in #14675, I happened to look at the x86_64 assembly for `stg_enter_info`, through gdb: {{{#!asm Breakpoint 2, stg_enter_info () at rts/HeapStackCheck.cmm:166 166 { (gdb) disassemble Dump of assembler code for function stg_enter_info: => 0x0000000002cf5900 <+0>: mov 0x0(%rbp),%rax 0x0000000002cf5904 <+4>: mov 0x8(%rbp),%rax 0x0000000002cf5908 <+8>: test $0x7,%al 0x0000000002cf590a <+10>: jne 0x2cf593d <stg_enter_info+61> 0x0000000002cf590c <+12>: mov (%rax),%rbx 0x0000000002cf590f <+15>: cmpl $0x1a,-0x8(%rbx) 0x0000000002cf5913 <+19>: jb 0x2cf5947 <stg_enter_info+71> 0x0000000002cf5915 <+21>: cmpl $0x1c,-0x8(%rbx) 0x0000000002cf5919 <+25>: jb 0x2cf592d <stg_enter_info+45> 0x0000000002cf591b <+27>: cmpl $0x1d,-0x8(%rbx) 0x0000000002cf591f <+31>: jb 0x2cf5933 <stg_enter_info+51> 0x0000000002cf5921 <+33>: mov %rbx,%rcx 0x0000000002cf5924 <+36>: mov %rax,%rbx 0x0000000002cf5927 <+39>: add $0x10,%rbp 0x0000000002cf592b <+43>: jmpq *%rcx 0x0000000002cf592d <+45>: cmpl $0x1b,-0x8(%rbx) 0x0000000002cf5931 <+49>: jb 0x2cf5921 <stg_enter_info+33> 0x0000000002cf5933 <+51>: mov 0x8(%rax),%rax 0x0000000002cf5937 <+55>: mov %rax,0x8(%rbp) 0x0000000002cf593b <+59>: jmp 0x2cf5908 <stg_enter_info+8> 0x0000000002cf593d <+61>: mov %rax,%rbx 0x0000000002cf5940 <+64>: add $0x10,%rbp 0x0000000002cf5944 <+68>: jmpq *0x0(%rbp) 0x0000000002cf5947 <+71>: cmpl $0xf,-0x8(%rbx) 0x0000000002cf594b <+75>: jb 0x2cf5969 <stg_enter_info+105> 0x0000000002cf594d <+77>: cmpl $0x19,-0x8(%rbx) 0x0000000002cf5951 <+81>: jb 0x2cf595d <stg_enter_info+93> 0x0000000002cf5953 <+83>: mov %rax,%rbx 0x0000000002cf5956 <+86>: add $0x10,%rbp 0x0000000002cf595a <+90>: jmpq *0x0(%rbp) 0x0000000002cf595d <+93>: movslq -0x8(%rbx),%rcx 0x0000000002cf5961 <+97>: cmp $0x17,%rcx 0x0000000002cf5965 <+101>: jne 0x2cf5921 <stg_enter_info+33> 0x0000000002cf5967 <+103>: jmp 0x2cf5953 <stg_enter_info+83> 0x0000000002cf5969 <+105>: cmpl $0x8,-0x8(%rbx) 0x0000000002cf596d <+109>: jb 0x2cf5921 <stg_enter_info+33> 0x0000000002cf596f <+111>: movslq -0x8(%rbx),%rbx 0x0000000002cf5973 <+115>: add $0xfffffffffffffff8,%rbx 0x0000000002cf5977 <+119>: jmpq *0x2e36d90(,%rbx,8) }}} Notice the first two instructions: {{{#!asm mov 0x0(%rbp),%rax mov 0x8(%rbp),%rax }}} We successively write two different things to `rax`, making the first `mov` effectively useless. I'm not quite sure the impact is of any significance but it still seems worth writing this down and addressing it at some point in the future, as there's just no way that first instruction will ever be useful. I think the assembly is generated from [https://github.com/ghc/ghc/blob/master/rts/HeapStackCheck.cmm#L164 this code], which in turns call [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L301 `ENTER`], which in turns calls [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L272 `LOAD_INFO`], which appears to rcorrespond to the first few instructions in the assembly I pasted, if we ignore the extra `mov`. (Assembly generated by ghc 8.4.1 built from the same commit as the alpha1 for 8.4.1 from hvr's PPA, in a 64bits Ubuntu VM. Not sure we generate a dead `mov` with the other codegens, haven't tested.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14739: Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures
by GHC 02 Feb '18

02 Feb '18

#14739: Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures -------------------------------------+------------------------------------- Reporter: mitchty | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Noticed while trying to build ghc 8.2.1, and ghc 8.2.2 on alpine linux armhf as well as nixos. Opening this ticket as I previously thought this was just some quirk of the alpine linux port but managed to find out from dhess on irc that nixos hits the same issue for both as well on armv7l arches. What happens. 8.2.1 logs, 8.2.2 has similar or the same issues, I was just double checking that 8.2.1 has the same problems. {{{ "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packag es -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock-library/vendor/attoparsec-0.13.1. 0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build /haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP- DIN_GHC_TREE -optP-include -optPutils/haddock/dis t/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -package- id filepath-1.4.1.2 -package-id directory-1. 3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.0.2 -package-id ghc-boot-8.2.1 -package-id ghc-8.2.1 -package-id bytestring-0.10.8.2 -package-i d transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsop ts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir uti ls/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock-api/src/Haddock/Backends/Hyperlink er/Types.hs -o utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packag es -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock-library/vendor/attoparsec-0.13.1. 0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build /haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP- DIN_GHC_TREE -optP-include -optPutils/haddock/dis t/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -package- id filepath-1.4.1.2 -package-id directory-1. 3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.0.2 -package-id ghc-boot-8.2.1 -package-id ghc-8.2.1 -package-id bytestring-0.10.8.2 -package-i d transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsop ts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir uti ls/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock-library/src/Documentation/Haddock/ Types.hs -o utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Segmentation fault (core dumped) make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/ResponseFile.dyn_o] Segmentation fault (core dumped) make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Segmentation fault (core dumpe d) make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o] Segmentation fault (core dumped) $ gdb /home/build/aports/community/ghc/src/ghc-8.2.1/inplace/lib/bin/ghc- stage2 src/ghc-8.2.1/core GNU gdb (GDB) 7.12.1 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "armv6-alpine-linux-musleabihf". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/build/aports/community/ghc/src/ghc-8.2.1/inplace/lib/bin/ghc- stage2...done. [New LWP 24905] [New LWP 24908] bt Core was generated by `/home/build/aports/community/ghc/src/ghc-8.2.1/inplace/lib/bin/ghc-stage2 -B/ho'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0019d628 in stg_IND_STATIC_info () [Current thread is 1 (LWP 24905)] (gdb) bt #0 0x0019d628 in stg_IND_STATIC_info () #1 0xaffcfe1c in stg_newAlignedPinnedByteArrayzh$def () from /home/build/aports/community/ghc/src/ghc-8.2.1/rts/dist/build /libHSrts_thr-ghc8.2.1.so Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) }}} I've been poking around but i'm a bit out of my depth here in understanding the ghc rts here and debugging it as well. But its curious that only the stage2 compiler is having issues being built and not stage0 or stage1. If needed/desired I can provide access/login to this box for debugging but its sloooow, ~29 hours to do a build to this point. But I'm willing to help move things along, ghc on arm is one of the main reaons for the port to alpine linux and 8.0.2 works fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13511: ApplicativeDo incorrectly requiring Monad
by GHC 02 Feb '18

02 Feb '18

#13511: ApplicativeDo incorrectly requiring Monad -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- We ran into this bug in production, this is a simplified reproduction. The following program will not type check, requiring an unnecessary Monad instance: {{{ {-# LANGUAGE ApplicativeDo, GeneralizedNewtypeDeriving #-} import Data.Functor.Identity import Data.Monoid newtype A x = A (Identity x) deriving (Functor, Applicative) shouldWork :: A () shouldWork = do a <- pure () b <- pure () let ab = a <> b return ab }}} {{{ pepe:~/code/snippets$ ghci ApplicativeDoBug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ApplicativeDoBug.hs, interpreted ) ApplicativeDoBug.hs:10:14: error: • No instance for (Monad A) arising from a do statement • In the expression: do { a <- pure (); b <- pure (); let ab = a <> b; return ab } In an equation for ‘shouldWork’: shouldWork = do { a <- pure (); b <- pure (); let ab = ...; return ab } Failed, modules loaded: none. }}} There is a simple workaround, which worked for us in production: {{{ workaround :: A () workaround = do a <- pure () b <- pure () return $ let ab = a <> b in ab }}} I asked in #ghc and it seems this is not yet fixed in HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14674: Deferring more levity polymorphism checks in indefinite backpack modules
by GHC 02 Feb '18

02 Feb '18

#14674: Deferring more levity polymorphism checks in indefinite backpack modules -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Keywords: backpack | 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 is kind of a follow up issue to issue #13955. I'm able to get along a little further with the thing I'm trying to do. Here's a minimal example. The `number-example-a` and `number-example-b` sections are not really needed to trigger the problem. They are included as examples of how the signature might be instantiated. {{{ {-# LANGUAGE MagicHash #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} unit the-fam where module TheFamily where import Data.Kind import GHC.Types import GHC.Prim data Liftedness = Lifted | Unlifted data SingLiftedness (x :: Liftedness) where SingLifted :: SingLiftedness 'Lifted SingUnlifted :: SingLiftedness 'Unlifted type family LiftednessIntRep (x :: Liftedness) :: RuntimeRep where LiftednessIntRep 'Lifted = LiftedRep LiftednessIntRep 'Unlifted = IntRep type family LiftednessInt (x :: Liftedness) :: TYPE (LiftednessIntRep x) where LiftednessInt 'Lifted = Int LiftednessInt 'Unlifted = Int# unit number-indefinite where dependency the-fam signature NumberUnknown where import GHC.Types import TheFamily data MyLiftedness :: Liftedness module NumberStuff where import NumberUnknown import TheFamily identityInt :: LiftednessInt MyLiftedness -> LiftednessInt MyLiftedness identityInt i = i unit number-example-a where dependency the-fam module NumberUnknown where import GHC.Types import TheFamily type MyLiftedness = Lifted identityInt :: Int -> Int identityInt x = x unit number-example-b where dependency the-fam module NumberUnknown where import GHC.Types import GHC.Prim import TheFamily type MyLiftedness = Unlifted identityInt :: Int# -> Int# identityInt i = i unit main where dependency number-indefinite[NumberUnknown=number- example-a:NumberUnknown] module Main where import NumberStuff import GHC.Types main = print (identityInt 5) }}} Attempting to compile with the ghc 8.4 release candidate gives: {{{ > /usr/local/bin/ghc-8.4.0.20171214 --backpack small_levity_backpack.bkp small_levity_backpack.bkp:35:17: error: A levity-polymorphic type is not allowed here: Type: LiftednessInt MyLiftedness Kind: TYPE (LiftednessIntRep MyLiftedness) In the type of binder ‘i’ | 35 | identityInt i = i | ^ }}} I disagree with this error. The type of `i` is not actually levity polymorphic in either of the example instantiations of the signature. If this check were omitted from the type-checking of the indefinite module, I suspect that this code should be able to compile and run fine. I'm not sure if there's a good general rule for when to suppress these checks in indefinite modules and when to not suppress them. Clearly, there are some cases were a function will with a levity-polymorphic binder no matter how the signature is fulfilled, and those ideally should continue to be rejected. And there are other cases like the one I raise here where it's guaranteed to be safe. There are other cases where the whether or not there's a levity-polymorphic binder depends on the instantiation: {{{ data X = X1 | X2 type family Rep (a :: X) (r :: RuntimeRep) :: RuntimeRep Rep X1 r = r Rep X2 r = UnliftedRep }}} And then finally, there are situations where it's always going to lead to a levity-polymorphic binder, but it isn't feasible for the compiler to figure that out. A sufficiently tricky type family would cause this. Sorry this was a bit of a ramble. I think there actually is a good rule for this. Defer the levity-polymorphic binder check in indefinite modules any time the type-checker encounters a type variable whose RuntimeRep is a type family that cannot be reduced. The check will happen later any way, and more correct code will be accepted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14751: GHC wrongly warns of incomplete pattern matches when using pattern synonyms.
by GHC 01 Feb '18

01 Feb '18

#14751: GHC wrongly warns of incomplete pattern matches when using pattern synonyms. -------------------------------------+------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If one writes the following code: {{{ {-# LANGUAGE PatternSynonyms #-} module Version where newtype Version = Version [Integer] deriving (Eq) pattern V :: [Integer] -> Version pattern V is = Version is instance Ord Version where (V []) <= (V []) = True (V []) <= _ = True _ <= (Version []) = False (V (x:xs)) <= (V (y:ys)) | x == y = Version xs <= Version ys | otherwise = x <= y }}} and compiles with {{{ghc -Wall -Werror}}}, one gets the following message: {{{ [1 of 1] Compiling Version ( Bug.hs, Bug.o ) Bug.hs:12:5: error: [-Wincomplete-patterns, -Werror=incomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘<=’: Patterns not matched: _ _ _ _ _ _ _ _ | 12 | (V []) <= (V []) = True | ^^^^^^^^^^^^^^^^^^^^^^^... }}} However, the following code compiles correctly without warnings: {{{ {-# LANGUAGE PatternSynonyms #-} module Version where newtype Version = Version [Integer] deriving (Eq) instance Ord Version where (Version []) <= (Version []) = True (Version []) <= _ = True _ <= (Version []) = False (Version (x:xs)) <= (Version (y:ys)) | x == y = Version xs <= Version ys | otherwise = x <= y }}} This bug appears in GHC 8.2.2 as well as GHC-8.4.1-alpha2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14661: Cannot derive (newtype I a b = I (F a -> F b) deriving newtype Category) for type family F
by GHC 01 Feb '18

01 Feb '18

#14661: Cannot derive (newtype I a b = I (F a -> F b) deriving newtype Category) for type family F -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple DerivingStrategies, deriving, | TypeFamilies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This works fine {{{#!hs {-# Language PolyKinds #-} {-# Language GADTs #-} {-# Language GeneralizedNewtypeDeriving #-} {-# Language InstanceSigs #-} {-# Language RankNTypes #-} {-# Language ScopedTypeVariables #-} {-# Language StandaloneDeriving #-} {-# Language TypeApplications #-} {-# Language DataKinds #-} {-# Language DerivingStrategies #-} {-# Language TypeFamilies #-} import Data.Kind import Control.Category import Prelude hiding (id, (.)) import Data.Coerce data TY = TI | TB type family Interp ty where Interp TI = Int Interp TB = Bool newtype Ixed :: TY -> TY -> Type where Ixed :: (Interp ix -> Interp ix') -> (Ixed ix ix') -- deriving newtype Category instance Category Ixed where id :: forall a. Ixed a a id = coerce (id @(->) @(Interp a)) (.) :: forall b c a. Ixed b c -> Ixed a b -> Ixed a c (.) = coerce ((.) @(->) @(Interp b) @(Interp c) @(Interp a)) }}} This instance can **not** be derived using `newtype` deriving. Commenting the `Category`-instance out and uncommenting `deriving newtype Category` results in an error {{{ $ ghci2 -ignore-dot-ghci hs/164-trac.hs GHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/164-trac.hs, interpreted ) hs/164-trac.hs:28:20: error: • Can't make a derived instance of ‘Category Ixed’ with the newtype strategy: cannot eta-reduce the representation type enough • In the newtype declaration for ‘Ixed’ | 28 | deriving newtype Category | ^^^^^^^^ Failed, no modules loaded. Prelude> }}} I may have asked this before, but can we make GHC smart enough to derive this instance? It consists entirely of the right visible type application of `method`: `method = coerce (method @a @b @..)` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14661> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15