April 2014 - ghc-tickets

[GHC] #8391: FunDeps coverage condition check failure with PolyKinds
by GHC 15 Apr '15

15 Apr '15

#8391: FunDeps coverage condition check failure with PolyKinds ----------------------------+---------------------------------------------- Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #8356 | ----------------------------+---------------------------------------------- The following code: {{{ #!haskell {-# LANGUAGE FunctionalDependencies, FlexibleInstances, UndecidableInstances, TypeFamilies, PolyKinds #-} module FunDepsIssue where type Foo a = a class Foo a ~ b => Bar a b | a -> b instance Foo a ~ b => Bar a b }}} results in: {{{ Illegal instance declaration for ‛Bar k a b’ Multiple uses of this instance may be inconsistent with the functional dependencies of the class. In the instance declaration for ‛Bar a b’ }}} This appears to be a regression from 7.6.3, where it compiles OK. The same error occurs when the type synonym is replaced with a type family (which is the case I was originally interested in) or a type constructor like `Data.Proxy`, as long as it's poly-kinded it seems. So the following cases also fail to compile: {{{ #!haskell type family Foo (a :: k) :: * type family Foo (a :: *) :: k type family Foo (a :: k) :: k type family Foo (a :: k) :: k' }}} Looking through the source code, I think that the issue is that the coverage condition check doesn't close over kind variables, when it compares the vars on each side of the functional dependency. But `Foo a` has a hidden kind variable, so the l.h. varset `{a}` is insufficient to fix `b` using `Foo a ~ b`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux
by GHC 14 Apr '15

14 Apr '15

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- After setting `BuildFlavor = perf` in `build.mk` compilation ends with a panic: {{{ "/home/luite/buildtest/ghc-clean-buildtest/ghc/inplace/bin/haddock" --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --no-tmp-comp- dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim /ghc-prim.haddock --html --hoogle --title="ghc-prim-0.3.1.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock- prologue.txt" --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-H32m --optghc=-O --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist- install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc- prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc =-optP-include --optghc=-optPlibraries/ghc-prim/dist- install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build --source- module=src/%{MODULE/./-}.html --source- entity=src/%{MODULE/./-}.html#%{NAME} libraries/ghc- prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc- prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim /dist-install/build/GHC/PrimopWrappers.hs libraries/ghc- prim/./GHC/PrimWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries /ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine- readable Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' 78% ( 7 / 9) in 'GHC.Types' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /351) in 'GHC.PrimopWrappers' 2% ( 1 / 43) in 'GHC.PrimWrappers' 17% ( 1 / 6) in 'GHC.CString' 31% (170 /540) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' haddock: internal error: haddock: panic! (the 'impossible' happened) (GHC version 7.7.20130912 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.newSession or GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc- prim.haddock] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 }}} I've seen this problem before, but I thought that it was related to my patch. Now I got it on master branch and Luite reported the same problem on #ghc (log above is actually his). A workaround for this is disabling building of dicumentation in "perf" section of `build.mk`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 50

[GHC] #8057: PackageImports with versions for ghci
by GHC 06 Apr '15

06 Apr '15

#8057: PackageImports with versions for ghci ------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: | ------------------------------------+------------------------------------- Imports with explicit package names and versions would be nice to have in GHCi, because you cannot use the -package and -hide-package options from within GHCi. This is what currently happens: {{{ $ ghci-7.6.3 -XPackageImports GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> import Control.Monad.Trans.List <no location info>: Ambiguous module name `Control.Monad.Trans.List': it was found in multiple packages: transformers-0.3.0.0 List-0.5.1 Prelude> import "transformers-0.3.0.0" Control.Monad.Trans.List <no location info>: Could not find module `Control.Monad.Trans.List' It is not a module in the current program, or in any known package. Prelude> :q Leaving GHCi. $ ghci-7.6.3 -hide-package List GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> import Control.Monad.Trans.List Prelude Control.Monad.Trans.List> }}} However, I now see that the import with explicit package name works, if I omit the package version. I think GHCi should at least warn that providing a version does not work. See also #2362 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8057> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8811: Profiling output jumbled together
by GHC 06 Apr '15

06 Apr '15

#8811: Profiling output jumbled together ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- In the time profile (-p), if the MODULE column is very wide and the no. column is also very wide they will run together with no space between. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8811> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8879: System.IO.Error documentation refers to invalid module Control.Exception.Exception
by GHC 27 Mar '15

27 Mar '15

#8879: System.IO.Error documentation refers to invalid module Control.Exception.Exception -------------------------------------+------------------------------------- Reporter: shadewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- See: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1 /System-IO-Error.html The description for IOError refers to module Control.Exception.Exception: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1 /Control-Exception-Exception.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8879> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8877: "if this code is reached, the program will abort" in sparc
by GHC 24 Mar '15

24 Mar '15

#8877: "if this code is reached, the program will abort" in sparc ----------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: sparc | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8857 | ----------------------------+------------------------------------- Hi, sparc, when built with dynamic libraries, fails with a segmentation fault: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc&ver=7.8.20140… Possible cause indicated by {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o rts/dist/build/Apply.o /tmp/ghc14927_0/ghc14927_2.hc: In function 'stg_PAP_entry': /tmp/ghc14927_0/ghc14927_2.hc:101:30: warning: function called through a non-compatible type [enabled by default] /tmp/ghc14927_0/ghc14927_2.hc:101:30: note: if this code is reached, the program will abort }}} It works without shared libraries (see #8857) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8877> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8872: hsc cast size warnings on 32-bit Linux
by GHC 24 Mar '15

24 Mar '15

#8872: hsc cast size warnings on 32-bit Linux ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When compiling the gtk package with GHC 7.9.20140308 I get a bunch of warnings as outlined below. I'm on 32-bit system. Apparently this is something that should be reported. {{{ In file included from dist/dist-sandbox- c4fc5f8b/build/Graphics/UI/Gtk/General/Structs_hsc_make.c:1:0: Structs.hsc: In function ‘main’: /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1020:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1020:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1025:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1025:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1029:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1029:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1033:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1033:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1037:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1037:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1042:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1042:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1046:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1046:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1051:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8872> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0
by GHC 24 Mar '15

24 Mar '15

#8976: dll-split: internal error: evacuate(static): strange closure type 0 -------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------+---------------------------------------- ghc-7.8.1 fails to build on Fedora ARM. This appears to be a regression compared to 7.8.1 RC2. {{{ : chmod +x inplace/bin/runghc inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.1 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Aborted }}} This is the bug report! This happens on both Fedora 20 (current latest stable release) and 21 (in development). The build is against ghc-7.6.3 and llvm 3.3 and 3.4 respectively. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8976> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8550: GHC builds recursive coerctions when using recursive type families
by GHC 23 Mar '15

23 Mar '15

#8550: GHC builds recursive coerctions when using recursive type families -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Consider {{{ {-# LANGUAGE TypeFamilies, GADTs, UndecidableInstances #-} type family F a type instance F () = F () data A where A :: F () ~ () => A x :: A x = A }}} On GHC 7.6.3 it yields a context reduction stack overflow (despite F () ~ () being put into the “solved funeqs” list). In HEAD, a recursive dictionary is built, but then detected: {{{ [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131108 for x86_64-unknown-linux): Cycle in coercion bindings [[cobox_ayX{v} [lid] = CO main:Foo.TFCo:R:F(){tc rob}[0] ; cobox_ayZ{v} [lid], cobox_ayZ{v} [lid] = CO cobox_ayX{v} [lid] ; cobox_az0{v} [lid]]] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Either this panic needs to be turned into an error, or we need to prevent recursive dictionaries for when solving funeqs (similar to how we do it for `Coercible`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8550> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8556: Invalid constructor names are accepted in data declarations
by GHC 23 Mar '15

23 Mar '15

#8556: Invalid constructor names are accepted in data declarations ------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Earlier today, someone was asking on #haskell why the constructor name {{{(^)}}} wouldn't work in GADT definitions. My response was that {{{(^)}}} isn't a constructor name, but much to my surprise, GHC accepts such names in a regular data declaration: {{{ data Foo = F | (^^^^) Int Int }}} This creates a {{{Foo}}} type and value constructor {{{F}}}, but no value constructor {{{(^^^^)}}}. However, in 7.6.3, if DataKinds are enabled, both constructors appear at the type level. In HEAD, the same definition is accepted, with only {{{F}}} existing at the value level, as before. But at the type level, both {{{F}}} and {{{(^^^^)}}} just generate errors that {{{Foo}}} is not a promotable type. At that point, I think there's no question that the declaration should just be ruled out. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8556> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3