September 2018 - ghc-tickets

[GHC] #14225: "No module named ... is imported" message is a bit misleading with qualified imports
by GHC 12 Dec '18

12 Dec '18

#14225: "No module named ... is imported" message is a bit misleading with qualified imports -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | 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: -------------------------------------+------------------------------------- It seems that the `No module named ... is imported` message produced in response to out-of-scope identifiers doesn't account for qualified imports. For instance, {{{ $ ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ben/.ghci λ> import qualified Data.Maybe as M λ> M.fromJusr <interactive>:2:1: error: Not in scope: ‘M.fromJusr’ Perhaps you meant ‘M.fromJust’ (imported from Data.Maybe) No module named ‘M’ is imported. λ> }}} I suppose there is the question of whether we consider `M` to be a "module" here; I would argue that I imported it and therefore the message is at very least a bit misleading. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15270: TH doesn't verify name types during conversion
by GHC 12 Dec '18

12 Dec '18

#15270: TH doesn't verify name types during conversion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 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: -------------------------------------+------------------------------------- Angerman reported that a use of the [[http://hackage.haskell.org/package /deriving-compat-0.4.2/docs/src/Data.Eq.Deriving.Internal.html#deriveEq1 `deriveEq`]] splice is causing GHC to abort with an assertion failure: {{{#!hs zonkExpr env (HsVar x (L l id)) = ASSERT2( isNothing (isDataConId_maybe id), ppr id ) return (HsVar x (L l (zonkIdOcc env id))) }}} I suspect the `deriveEq1` is calling `varE` with a DataCon name. We should catch this case and throw a better error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13897: Ship check-ppr in bindist and compile during testsuite run
by GHC 11 Dec '18

11 Dec '18

#13897: Ship check-ppr in bindist and compile during testsuite run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- Currently `check-ppr` is built during the compiler build and used by the testsuite in the pretty-printer tests. In a source checkout this is fine, however this arrangement blows up in the case of a binary distribution as we don't (and probably shouldn't) ship the `check-ppr` binary in the bindist. I think the most reasonable way to deal with this is to instead ship the `check-ppr` source (perhaps in the testsuite tarball) and build it as a dependency of the testsuite. Ideally we would build the executable once and use it for each of the ppr tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13897> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15608: Segfault in retainer profiling
by GHC 11 Dec '18

11 Dec '18

#15608: Segfault in retainer profiling -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.5 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 reproduce, build ghc using "prof" flavor, then {{{ $ ghc-stage2 --interactive +RTS -hr GHCi, version 8.7.20180905: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> sequence_ (replicate 100000000 (return ())) zsh: segmentation fault (core dumped) ghc-stage2 --interactive +RTS -hr }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15444: 8.4.3 has an undocumented dependency on libnuma.
by GHC 11 Dec '18

11 Dec '18

#15444: 8.4.3 has an undocumented dependency on libnuma. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- See also https://github.com/haskell/network/issues/328 for some discussion. The issue seems to be that the rts "package" depends on libnuma. See below for build log and rts package info. {{{ The Glorious Glasgow Haskell Compilation System, version 8.4.3 cabal-install version 2.2.0.0 compiled using version 2.2.0.0 of the Cabal library - network-2.6.3.5 (lib:network) (requires build) }}} {{{ checking for netdb.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking linux/can.h usability... yes checking linux/can.h presence... yes checking for linux/can.h... yes checking linux/tcp.h usability... yes checking linux/tcp.h presence... yes checking for linux/tcp.h... yes checking net/if.h usability... yes checking net/if.h presence... yes checking for net/if.h... yes checking for readlink... yes checking for symlink... yes checking for if_nametoindex... yes checking for struct msghdr.msg_control... yes checking for struct msghdr.msg_accrights... no checking for struct sockaddr.sa_len... no checking for in_addr_t in netinet/in.h... yes checking for SO_PEERCRED and struct ucred in sys/socket.h... yes checking for getpeereid in unistd.h... checking for getpeereid... no checking for _head_libws2_32_a in -lws2_32... no checking for getaddrinfo... yes checking for gai_strerror... yes checking whether AI_ADDRCONFIG is declared... yes checking whether AI_ALL is declared... yes checking whether AI_NUMERICSERV is declared... yes checking whether AI_V4MAPPED is declared... yes checking whether IPV6_V6ONLY is declared... yes checking whether IPPROTO_IP is declared... yes checking whether IPPROTO_TCP is declared... yes checking whether IPPROTO_IPV6 is declared... yes checking for sendfile in sys/sendfile.h... yes checking for sendfile in sys/socket.h... no checking for gethostent... yes checking for accept4... yes configure: creating ./config.status config.status: creating network.buildinfo config.status: creating include/HsNetworkConfig.h configure: WARNING: unrecognized options: --with-compiler Preprocessing library for network-2.6.3.5.. /usr/bin/ld.gold: error: cannot find -lnuma collect2: error: ld returned 1 exit status linking dist/build/Network/BSD_hsc_make.o failed (exit code 1) command was: /usr/bin/gcc dist/build/Network/BSD_hsc_make.o dist/build/Network/BSD_hsc_utils.o -o dist/build/Network/BSD_hsc_make -fuse-ld=gold -fno-stack-protector -fuse-ld=gold -L/usr/local/lib/ghc-8.4.3/unix-2.7.2.2 -Wl,-R,/usr/local/lib/ghc-8.4.3/unix-2.7.2.2 -lrt -lutil -ldl -lpthread -L/usr/local/lib/ghc-8.4.3/time-1.8.0.2 -Wl,-R,/usr/local/lib/ghc-8.4.3/time-1.8.0.2 -L/usr/local/lib/ghc-8.4.3/bytestring-0.10.8.2 -Wl,-R,/usr/local/lib/ghc-8.4.3/bytestring-0.10.8.2 -L/usr/local/lib/ghc-8.4.3/deepseq-1.4.3.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/deepseq-1.4.3.0 -L/usr/local/lib/ghc-8.4.3/array-0.5.2.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/array-0.5.2.0 -L/usr/local/lib/ghc-8.4.3/base-4.11.1.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/base-4.11.1.0 -L/usr/local/lib/ghc-8.4.3 /integer-gmp-1.0.2.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/integer-gmp-1.0.2.0 -lgmp -L/usr/local/lib/ghc-8.4.3/ghc-prim-0.5.2.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/ghc-prim-0.5.2.0 -L/usr/local/lib/ghc-8.4.3/rts -Wl,-R,/usr/local/lib/ghc-8.4.3/rts -lm -lrt -ldl -lnuma -lpthread cabal: Failed to build exe:hsc2hs from hsc2hs-0.68.3 (which is required by cabal-install-2.2.0.0). See the build log above for details. Failed to build network-2.6.3.5 (which is required by cabal- install-2.2.0.0). See the build log above for details. }}} {{{ name: rts version: 1.0 id: rts key: rts license: BSD-3-Clause maintainer: glasgow-haskell-users(a)haskell.org exposed: True library-dirs: /usr/local/lib/ghc-8.4.3/rts hs-libraries: HSrts Cffi extra-libraries: m rt dl numa pthread include-dirs: /usr/local/lib/ghc-8.4.3/include includes: Stg.h ld-options: "-Wl,-u,base_GHCziTopHandler_runIO_closure" "-Wl,-u,base_GHCziTopHandler_runNonIO_closure" "-Wl,-u,ghczmprim_GHCziTuple_Z0T_closure" "-Wl,-u,ghczmprim_GHCziTypes_True_closure" "-Wl,-u,ghczmprim_GHCziTypes_False_closure" "-Wl,-u,base_GHCziPack_unpackCString_closure" "-Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure" "-Wl,-u,base_GHCziIOziException_stackOverflow_closure" "-Wl,-u,base_GHCziIOziException_heapOverflow_closure" "-Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure" "-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure" "-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure" "-Wl,-u,base_GHCziIOziException_cannotCompactFunction_closure" "-Wl,-u,base_GHCziIOziException_cannotCompactPinned_closure" "-Wl,-u,base_GHCziIOziException_cannotCompactMutable_closure" "-Wl,-u,base_ControlziExceptionziBase_absentSumFieldError_closure" "-Wl,-u,base_ControlziExceptionziBase_nonTermination_closure" "-Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure" "-Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure" "-Wl,-u,base_GHCziConcziSync_runSparks_closure" "-Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure" "-Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure" "-Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure" "-Wl,-u,base_GHCziTopHandler_flushStdHandles_closure" "-Wl,-u,base_GHCziTopHandler_runMainIO_closure" "-Wl,-u,ghczmprim_GHCziTypes_Czh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Izh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Wzh_con_info" "-Wl,-u,base_GHCziPtr_Ptr_con_info" "-Wl,-u,base_GHCziPtr_FunPtr_con_info" "-Wl,-u,base_GHCziInt_I8zh_con_info" "-Wl,-u,base_GHCziInt_I16zh_con_info" "-Wl,-u,base_GHCziInt_I32zh_con_info" "-Wl,-u,base_GHCziInt_I64zh_con_info" "-Wl,-u,base_GHCziWord_W8zh_con_info" "-Wl,-u,base_GHCziWord_W16zh_con_info" "-Wl,-u,base_GHCziWord_W32zh_con_info" "-Wl,-u,base_GHCziWord_W64zh_con_info" "-Wl,-u,base_GHCziStable_StablePtr_con_info" "-Wl,-u,hs_atomic_add8" "-Wl,-u,hs_atomic_add16" "-Wl,-u,hs_atomic_add32" "-Wl,-u,hs_atomic_add64" "-Wl,-u,hs_atomic_sub8" "-Wl,-u,hs_atomic_sub16" "-Wl,-u,hs_atomic_sub32" "-Wl,-u,hs_atomic_sub64" "-Wl,-u,hs_atomic_and8" "-Wl,-u,hs_atomic_and16" "-Wl,-u,hs_atomic_and32" "-Wl,-u,hs_atomic_and64" "-Wl,-u,hs_atomic_nand8" "-Wl,-u,hs_atomic_nand16" "-Wl,-u,hs_atomic_nand32" "-Wl,-u,hs_atomic_nand64" "-Wl,-u,hs_atomic_or8" "-Wl,-u,hs_atomic_or16" "-Wl,-u,hs_atomic_or32" "-Wl,-u,hs_atomic_or64" "-Wl,-u,hs_atomic_xor8" "-Wl,-u,hs_atomic_xor16" "-Wl,-u,hs_atomic_xor32" "-Wl,-u,hs_atomic_xor64" "-Wl,-u,hs_cmpxchg8" "-Wl,-u,hs_cmpxchg16" "-Wl,-u,hs_cmpxchg32" "-Wl,-u,hs_cmpxchg64" "-Wl,-u,hs_atomicread8" "-Wl,-u,hs_atomicread16" "-Wl,-u,hs_atomicread32" "-Wl,-u,hs_atomicread64" "-Wl,-u,hs_atomicwrite8" "-Wl,-u,hs_atomicwrite16" "-Wl,-u,hs_atomicwrite32" "-Wl,-u,hs_atomicwrite64" pkgroot: "/usr/local/lib/ghc-8.4.3" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9718: Avoid TidyPgm predicting what CorePrep will do
by GHC 11 Dec '18

11 Dec '18

#9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment the `TidyPgm` pass is forced to predict, accurately but unpleasantly, some aspects of what `CorePrep` and `Core2Stg` will do. Reason: * Each `Id` in the interface file records (among other things) the '''arity''' of the `Id`, and whether it has '''CAF references''' * We really only know these two things for sure after `CorePrep`. The conversion from Core to STG makes no structural changes. * However the result of `TidyPgm` (which preceded `CorePrep`) is used to generate the interface file. So it has to predict the arity and CAF-ref status of each `Id`. * This is not good. It restricts what `CorePrep` can do (notably, it must not change the arity of a top-level `Id`), and it leads to unsavoury code (e.g. look at the call to `CorePrep.cvtLitInteger` in `TidyPgm.cafRefsL`. It's also dangerous: an inconsistency could lead to a crash. This is a long-standing problem. My current thought for how to unravel it is this: * `TidyPgm` does not attach arity or CAF-ref info. * Instead, run `CorePrep` after `TidyPgm`, and generate accurate arity and CAF-ref info * Then use that auxiliary mapping during the conversion from tidied program to `ModIface`. I don't think this would be hard. It would mean that the tidied program and the core-prep'd program would have to exist in memory at the same time. An alternative would be to generate the `ModIface` from the tidied program ''sans'' arity and CAF-ref info, and then, after `CorePrep` run over it to add arity and CAF-ref info. (You'd have to do this before generating the fingerprints.) The advantage of this is that the `ModIface` can be a lot smaller than the code for the entire module. A long-standing wart which needs some careful attention. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 42

[GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks
by GHC 10 Dec '18

10 Dec '18

#14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | 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 #14222 it was noted that something appears to be broken in `CmmCommonBlockElim`. Consider the program from that ticket, {{{#!hs module T14221 where import Data.Text as T isNumeric :: Text -> Bool isNumeric t = T.all isNumeric' t && T.any isNumber t where isNumber c = '0' <= c && c <= '9' isNumeric' c = isNumber c || c == 'e' || c == 'E' || c == '.' || c == '-' || c == '+' }}} This program produces six copies of a block of the form, {{{#!c c6JT: R2 = I64[R1 + 7]; R1 = P64[Sp + 8]; Sp = Sp + 16; call $wloop_all_s6CQ_info(R2, R1) args: 8, res: 0, upd: 8; }}} in the `-ddump-opt-cmm` output, which are manifest in the assembler as, {{{#!asm block_c6JT_info: _c6JT: movq 7(%rbx),%r14 movq 8(%rbp),%rbx addq $16,%rbp jmp $wloop_all_s6CQ_info }}} CBE really ought to be catching these. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #12893: Profiling defeats stream fusion when using vector library
by GHC 10 Dec '18

10 Dec '18

#12893: Profiling defeats stream fusion when using vector library -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: stream-fusion | Operating System: MacOS X profiling | Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have this problem where enabling profiling in Haskell undoes stream fusion and I’d like to do my profiling with stream fusion intact. The following reproduces my problem: {{{ $ git clone git@github.com:haskell-works/hw-tutorial-performance.git $ cd hw-tutorial-performance/ $ stack init $ stack build --executable-profiling $ time $(find .stack-work/dist/ -type f -name hw-tutorial-performance- rwhe) 1e7 5000000.5 real 0m4.432s user 0m3.484s sys 0m0.936s $ rm -rf .stack-work/ $ stack build $ time $(find .stack-work/dist/ -type f -name hw-tutorial-performance- rwhe) 1e7 5000000.5 real 0m0.034s user 0m0.018s sys 0m0.013s With profiling, my program takes over 4 seconds to run. Without profiling, it only takes 0.034 seconds. }}} The problem has nothing to do with stack. {{{ (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ ghc -fforce-recomp --make -O2 -funbox-strict-fields -rtsopts -optc-O2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ time ./Main +RTS -sstderr -RTS 1e7 5000000.5 115,888 bytes allocated in the heap 3,480 bytes copied during GC 44,384 bytes maximum residency (1 sample(s)) 17,056 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.000s 0.005s 0.0049s 0.0049s INIT time 0.000s ( 0.002s elapsed) MUT time 0.010s ( 0.025s elapsed) GC time 0.000s ( 0.005s elapsed) EXIT time 0.000s ( 0.005s elapsed) Total time 0.012s ( 0.037s elapsed) %GC time 1.8% (13.1% elapsed) Alloc rate 11,904,262 bytes per MUT second Productivity 97.1% of total user, 31.2% of total elapsed real 0m0.057s user 0m0.012s sys 0m0.010s (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ ghc -prof -fforce-recomp --make -O2 -funbox-strict-fields -rtsopts -optc-O2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ time ./Main +RTS -sstderr -RTS 1e7 5000000.5 3,012,099,000 bytes allocated in the heap 4,079,698,408 bytes copied during GC 1,162,199,352 bytes maximum residency (13 sample(s)) 19,313,368 bytes maximum slop 1990 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 4869 colls, 0 par 1.046s 1.055s 0.0002s 0.0017s Gen 1 13 colls, 0 par 1.230s 1.960s 0.1508s 0.5764s INIT time 0.000s ( 0.004s elapsed) MUT time 0.963s ( 0.825s elapsed) GC time 2.276s ( 3.016s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.009s ( 0.185s elapsed) Total time 3.251s ( 4.029s elapsed) %GC time 70.0% (74.8% elapsed) Alloc rate 3,126,345,026 bytes per MUT second Productivity 30.0% of total user, 24.2% of total elapsed real 0m4.197s user 0m3.251s sys 0m0.883s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12893> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13637: Printing type operators adds extraneous parenthesis
by GHC 10 Dec '18

10 Dec '18

#13637: Printing type operators adds extraneous parenthesis -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- Given the code: {{{ {-# LANGUAGE TypeOperators #-} type name ::: a = a f :: Int ::: Int -> Int f = id }}} In GHCi-8.0.2 I get: {{{ >>> :t f f :: Int ::: Int -> Int }}} But in GHCi-8.2.0.20170427 I get: {{{ >>> :t f f :: (Int ::: Int) -> Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8109: Type family patterns should support as-patterns.
by GHC 09 Dec '18

09 Dec '18

#8109: Type family patterns should support as-patterns. ------------------------------------+------------------------------------- Reporter: carlhowells | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- I recently wrote code similar to the following: {{{ {-# LANGUAGE DataKinds, ScopedTypeVariables, TypeOperators, TypeFamilies #-} {-# LANGUAGE PolyKinds, FlexibleInstances, FlexibleContexts #-} import GHC.TypeLits data P n = P fromNat :: forall (p :: Nat -> *) (n :: Nat). SingI n => p n -> Integer fromNat _ = fromSing (sing :: Sing n) class C (a :: [Nat]) where type T a :: * val :: p a -> T a instance SingI n => C '[n] where type T '[n] = Integer val _ = fromNat (P :: P n) instance (SingI n, C (n2 ': ns)) => C (n ': n2 ': ns) where type T (n ': n2 ': ns) = (Integer, T (n2 ': ns)) val _ = (fromNat (P :: P n), val (P :: P (n2 ': ns))) }}} There were semantic constraints in my case that made an empty list nonsensical, so it wasn't an appropriate base case. But the resulting effort in ensuring type family patterns didn't overlap got unwieldy. I would have much preferred to write that second instance more like this: {{{ instance (SingI n, C ns) => C (n ': ns@(_ ': _)) where type T (n ': ns) = (Integer, T ns) val _ = (fromNat (P :: P n), val (P :: P ns)) }}} The reasoning here is identical to as-patterns in value-level pattern matching. If you only want to match an expression when it has a particular sub-structure, it's way more convenient to do it with an as-pattern. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8109> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8