- ghc-devs - Haskell.org

Re: Reading floating point
by David Feuer 11 Oct '16

11 Oct '16

I fully expect this to be somewhat tricky, yes. But some aspects of the current implementation strike me as pretty clearly non-optimal. What I meant about going through Rational is that given "625e-5", say, it calculates 625%100000, producing a fraction in lowest terms, before calling fromRational, which itself invokes fromRat'', a division function optimized for a special case that doesn't seem too relevant in this context. I could be mistaken, but I imagine even reducing to lowest terms is useless here. The separate treatment of the digits preceding and following the decimal point doesn't do anything obviously useful either. If we (effectively) normalize in decimal to an integral mantissa, for example, then we can convert the whole mantissa to an Integer at once; this will balance the merge tree better than converting the two pieces separately and combining. On Oct 10, 2016 6:00 AM, "Yitzchak Gale" <gale(a)sefer.org> wrote: The way I understood it, it's because the type of "floating point" literals is Fractional a => a so the literal parser has no choice but to go via Rational. Once you have that, you use the same parser for those Read instances to ensure that the result is identical to what you would get if you parse it as a literal in every case. You could replace the Read parsers for Float and Double with much more efficient ones. But you would need to provide some other guarantee of consistency with literals. That would be more difficult to achieve than one might think - floating point is deceivingly tricky. There are already several good parsers in the libraries, but I believe all of them can provide different results than literals in some cases. YItz On Sat, Oct 8, 2016 at 10:27 PM, David Feuer <david.feuer(a)gmail.com> wrote: > The current Read instances for Float and Double look pretty iffy from an > efficiency standpoint. Going through Rational is exceedingly weird: we have > absolutely nothing to gain by dividing out the GCD, as far as I can tell. > Then, in doing so, we read the digits of the integral part to form an > Integer. This looks like a detour, and particularly bad when it has many > digits. Wouldn't it be better to normalize the decimal representation first > in some fashion (e.g., to 0.xxxxxxexxx) and go from there? Probably less > importantly, is there some way to avoid converting the mantissa to an > Integer at all? The low digits may not end up making any difference > whatsoever. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

3 8

when building latest GHC on Mac with Xcode 8: Symbol not found: _clock_gettime
by John Leo 11 Oct '16

11 Oct '16

Hi everyone, I'm trying to compile ghc from the latest source and am hitting an error "Symbol not found: _clock_gettime". I'm on Mac El Capitan and recently installed Xcode 8 which I'm sure is what caused the problem. Using Google I found some relevant pages including this one https://mail.haskell.org/pipermail/ghc-devs/2016-July/012511.html but I've been unable to figure out what I can do to fix the problem. Any help would be appreciated. The tail end of my compilation output is below. Thanks in advance. John cat ghc/ghc.wrapper >> inplace/bin/ghc-stage2 chmod +x inplace/bin/ghc-stage2 "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O -H64m -Wall -hide-all-packages -i -iutils/ghctags/. -iutils/ghctags/dist-install/build -Iutils/ghctags/dist-install/build -iutils/ghctags/dist-install/build/ghctags/autogen -Iutils/ghctags/dist-install/build/ghctags/autogen -optP-include -optPutils/ghctags/dist-install/build/ghctags/autogen/cabal_macros.h -package-id Cabal-1.25.0.0 -package-id base-4.9.0.0 -package-id containers-0.5.7.1 -package-id ghc-8.1 -XHaskell2010 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir utils/ghctags/dist-install/build -hidir utils/ghctags/dist-install/build -stubdir utils/ghctags/dist-install/build -c utils/ghctags/./Main.hs -o utils/ghctags/dist-install/build/Main.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O -H64m -Wall -hide-all-packages -i -iutils/check-api-annotations/. -iutils/check-api-annotations/dist-install/build -Iutils/check-api-annotations/dist-install/build -iutils/check-api-annotations/dist-install/build/check-api-annotations/autogen -Iutils/check-api-annotations/dist-install/build/check-api-annotations/autogen -optP-include -optPutils/check-api-annotations/dist-install/build/check-api-annotations/autogen/cabal_macros.h -package-id Cabal-1.25.0.0 -package-id base-4.9.0.0 -package-id containers-0.5.7.1 -package-id directory-1.2.6.2 -package-id ghc-8.1 -Wall -XHaskell2010 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir utils/check-api-annotations/dist-install/build -hidir utils/check-api-annotations/dist-install/build -stubdir utils/check-api-annotations/dist-install/build -c utils/check-api-annotations/./Main.hs -o utils/check-api-annotations/dist-install/build/Main.dyn_o dyld: lazy symbol binding failed: Symbol not found: _clock_gettime Referenced from: /Users/leo/haskell/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161010.dylib (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _clock_gettime Referenced from: /Users/leo/haskell/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161010.dylib (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib dyld: lazy symbol binding failed: Symbol not found: _clock_gettime Referenced from: /Users/leo/haskell/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161010.dylib (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _clock_gettime Referenced from: /Users/leo/haskell/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161010.dylib (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib make[1]: *** [utils/ghctags/dist-install/build/Main.dyn_o] Trace/BPT trap: 5 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/check-api-annotations/dist-install/build/Main.dyn_o] Trace/BPT trap: 5 make: *** [all] Error 2 i

2 2

RE: [Diffusion] [Build Failed] rGHCa6111b8cc14a: More tests for Trac #12522
by Simon Peyton Jones 10 Oct '16

10 Oct '16

This says “stat not good enough” for “max_bytes_used” on T1969. I pushed a “T1969 is ok” patch recently, because it IS ok on my (64-bit Linux) machine. If it’s not ok for our CI infrastructure, by all means un-push it or something. Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 10 October 2016 15:07 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHCa6111b8cc14a: More tests for Trac #12522 Harbormaster failed to build B11303: rGHCa6111b8cc14a: More tests for Trac #12522! BRANCHES master USERS simonpj (Author) O7 (Auditor) COMMIT https://phabricator.haskell.org/rGHCa6111b8cc14a EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

1 0

Reading floating point
by David Feuer 10 Oct '16

10 Oct '16

The current Read instances for Float and Double look pretty iffy from an efficiency standpoint. Going through Rational is exceedingly weird: we have absolutely nothing to gain by dividing out the GCD, as far as I can tell. Then, in doing so, we read the digits of the integral part to form an Integer. This looks like a detour, and particularly bad when it has many digits. Wouldn't it be better to normalize the decimal representation first in some fashion (e.g., to 0.xxxxxxexxx) and go from there? Probably less importantly, is there some way to avoid converting the mantissa to an Integer at all? The low digits may not end up making any difference whatsoever.

2 1

Allow top-level shadowing for imported names?
by Herbert Valerio Riedel 10 Oct '16

10 Oct '16

Hi *, I seem to recall this was already suggested in the past, but I can't seem to find it in the archives. For simplicity I'll restate the idea: foo :: Int -> Int -> (Int,Int) foo x y = (bar x, bar y) where bar x = x+x results merely in a name-shadowing warning (for -Wall): foo.hs:4:9: warning: [-Wname-shadowing] This binding for ‘x’ shadows the existing binding bound at foo.hs:2:5 However, import Data.Monoid (<>) :: String -> String -> String (<>) = (++) main :: IO () main = putStrLn ("Hi" <> "There") doesn't allow to shadow (<>), but rather complains about ambiguity: bar.hs:7:23: error: Ambiguous occurrence ‘<>’ It could refer to either ‘Data.Monoid.<>’, imported from ‘Data.Monoid’ at bar.hs:1:1-18 or ‘Main.<>’, defined at bar.hs:4:1 This is of course in line with the Haskell Report, which says in https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-101000… | The entities exported by a module may be brought into scope in another | module with an import declaration at the beginning of the module. The | import declaration names the module to be imported and optionally | specifies the entities to be imported. A single module may be imported | by more than one import declaration. Imported names serve as top level | declarations: they scope over the entire body of the module but may be | shadowed by *local non-top-level bindings.* However, why don't we allow this to be relaxed via a new language extensions, to allow top-level bindings to shadow imported names (and of course emit a warning)? Unless I'm missing something, this would help to keep existing and working code compiling if new versions of libraries start exporting new symbols (which happen to clash with local top-level defs), rather than resulting in a fatal name-clash; and have no major downsides. If this sounds like a good idea, I'll happily promote this into a proper proposal over at https://github.com/ghc-proposals/ghc-proposals; I mostly wanted to get early feedback here (and possibly find out if and where this was proposed before), before investing more time turning this into a fully fledged GHC proposal. Cheers, HVR

15 19

bkpcabal01 test failure on Mac OS X
by Ben Gamari 08 Oct '16

08 Oct '16

Hi Edward, Our new OS X build bot has noticed that the bkpcabal01 testcase introduced with your Backpack merge seems to fail on OS X with, =====> bkpcabal01(normal) 1 of 1 [0, 0, 0] cd "./backpack/cabal/bkpcabal01/bkpcabal01.run" && $MAKE -s --no-print-directory bkpcabal01 CLEANUP=1 Actual stderr output differs from expected: --- /dev/null 2016-10-08 22:51:23.000000000 +0300 +++ ./backpack/cabal/bkpcabal01/bkpcabal01.run/bkpcabal01.run.stderr.normalised 2016-10-08 22:51:23.000000000 +0300 @@ -0,0 +1,4 @@ +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-36887/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-36936/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-37078/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-37123/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols *** unexpected failure for bkpcabal01(normal) It seems that this message is produced by `ar` while building the .a archive, bkpcabal01 bgamari$ make SETUP="./Setup -v3" bkpcabal01 ... ("/usr/bin/ar",["-r","-s","-v","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o"]) ar: creating archive dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a a - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o a - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o /Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols I've opened #12673 to track this issue but until we have a chance to fix it I've enabled `ignore_stderr` to the testcase on Darwin. Cheers, - Ben

1 0

Type hole in pattern match
by amindfv＠gmail.com 08 Oct '16

08 Oct '16

Is this intended behavior?: foo :: _ (foo, _) = (True, True) Produces no warning or message at all even with -Wall Tom

3 2

[GHC Proposal] Optional tuple parenthesization
by Ben Gamari 07 Oct '16

07 Oct '16

Hello everyone, Iceland_Jack has just opened Pull Requests #18 [1] and #19 [2] against the ghc-proposals repository, describing a extensions to GHC's LambdaCase extension and pattern matching syntax on tuples. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/18 [2] https://github.com/ghc-proposals/ghc-proposals/pull/19

1 0

Travis broken (type checking patches by SPJ)
by Joachim Breitner 07 Oct '16

07 Oct '16

Hi, our secondary CI infrastructure is in bad shape since a week. The first push that broke it was the one ending with commit fc4ef66 by SPJ: * fc4ef66 - Comments only (vor 7 Tagen)<Simon Peyton Jones> * b612da6 - Fix impredicativity (again) (vor 7 Tagen)<Simon Peyton Jones> * 3012c43 - Add Outputable Report in TcErrors (vor 7 Tagen)<Simon Peyton Jones> * 66a8c19 - Fix a bug in occurs checking (vor 7 Tagen)<Simon Peyton Jones> * 2fbfbca - Fix desugaring of pattern bindings (again) (vor 7 Tagen)<Simon Peyton Jones> * 0b533a2 - A bit of tracing about flattening (vor 7 Tagen)<Simon Peyton Jones> https://github.com/ghc/ghc/compare/f21eedbc223c...fc4ef667ce2b --- /dev/null 2015-01-28 16:31:58.000000000 +0000 +++ /tmp/ghctest-gSX4vv/test spaces/./boxy/Base1.run/Base1.comp.stderr.normalised 2016-09-30 12:44:57.182659875 +0000 @@ -0,0 +1,18 @@ + +Base1.hs:20:13: + Couldn't match type â€˜a0 -> a0â€™ with â€˜forall a. a -> aâ€™ + Expected type: MEither Sid b + Actual type: MEither (a0 -> a0) b + In the expression: MLeft fid + In an equation for â€˜test1â€™: test1 fid = MLeft fid + +Base1.hs:25:39: + Couldn't match type â€˜a1 -> a1â€™ with â€˜forall a. a -> aâ€™ + Expected type: Maybe (Sid, Sid) + Actual type: Maybe (a1 -> a1, a2 -> a2) + In the expression: Just (x, y) + In a case alternative: MRight y -> Just (x, y) + In the expression: + case m of { + MRight y -> Just (x, y) + _ -> Nothing } *** unexpected failure for Base1(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): ASSERT failed! m_aAI Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1123:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for RaeBlogPost(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): ASSERT failed! m_awK Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1123:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for TypeLevelVec(normal) A subsequent commit by SPJ fixed the first one. It now compield without -DDEBUG again, but the other two failures (observable only with -DDEBUG) are still there. Since then, Travis has been reporting failures for the master branch. I only noticed now as I pushed something to master, and I got an email. Did you not get notifications about the breakage? If you did, was it unclear how to get to the log file? In any case: Simon, could you have a look and see if the ASSERT is pointing out a real bug introduced with your commits, or whether the ASSERT is wrong, so that we can build master with -DDEBUG again? Thanks, Joachim -- “Comments only” with this failure:Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

RE: Typeable meeting
by Simon Peyton Jones 07 Oct '16

07 Oct '16

Richard Ben and I concluded 1. Currently saturated (->) is treated differently to unsaturated (->), as witnessed by the special kinding rule for FunTy. The shortest path for TypeRep is to do the same: add TrFunTy. 1. Moreover we probably need FunCo for coercions; at the moment it's done with TyConAppCo, but that doesn't work with (->) :: * -> * -> *. Having FunCo would be (a) more efficient for a very common case, (b) deal with the kinding issue. 2. splitAppTy_maybe currently will split a FunTy even when it is not used at kind *. This is probably wrong. Maybe it should return Nothing in the non-* case. Ben is trying this out. 3. Orthogonally, one could imagine generalising the kind of prefix (->) to (->) :: forall r1 r2. TYPE r1 -> TYPE r2 -> Type LiftedPtrRep Then FunTy would become an abbreviation/optimisation, to avoid a plethora of runtime-rep args. And splitAppTy_maybe could succeed all the time on FunTy. Ben is trying this. 4. Under (3) at what kinds is ((->) ?? LiftedPtrRep (Ord Int) Char) called? If we continue to distinguish * from Constraint, we'd need to instantiate ?? with ConstraintRep, and define type Constraint = TYPE ConstraintRep Orthogonally, one might wonder about combining * and Constraint, but we don't yet know how to do that well. | -----Original Message----- | From: Richard Eisenberg [mailto:rae@cs.brynmawr.edu] | Sent: 06 October 2016 15:08 | To: Ben Gamari <ben(a)smart-cactus.org> | Cc: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: Typeable meeting | | Just seeing this now. (Please use my new address: rae(a)cs.brynmawr.edu) I | wasn't available yesterday at that time, anyway. | | Any conclusions reached? | | > On Oct 4, 2016, at 5:39 PM, Ben Gamari <ben(a)smart-cactus.org> wrote: | > | > Simon Peyton Jones <simonpj(a)microsoft.com> writes: | > | >> Ben, and copying Richard who is far better equipped to respond than | me. | >> | >> I'm way behind the curve here. | >> | >> If "this is precisely what mkFunCo does" why not use mkFunCo? Why do | >> you want to "generalise the arrow operation"? | >> | > Perhaps I should have said "this is what mkFunCo is supposed to do". | > However, mkFunCo needs to be adjusted under the generalized (->) | > scheme, since the (->) tycon will gain two additional type arguments | > (corresponding to the RuntimeReps of the argument and result types). | > mkFunCo needs to fill these type arguments when constructing its | result. | > | >> I'm lost as to your goal and the reason why you need to wade through | this particular swamp. | >> | > There are a few reasons, | > | > * We want to provide a pattern to match against function types | > | > pattern TrFun :: TypeRep arg -> TypeRep res -> TypeRep (arg -> | > res) | > | > * T11120 currently fails on my branch as it contains a TypeRep of a | > promoted type containing an unboxed type. Namely, | > | > import Data.Typeable | > data CharHash = CharHash Char# | > main = print $ typeRep (Proxy :: Proxy 'CharHash) | > | > Note how 'CharHash has kind Char# -> Type. This kind occurs in one of | > the terms in `typeRep` needed in the above program, which currently | > results in core lint failures due to the restrictive kind of (->). | > For this reason (->) needs to be polymorphic over runtime | > representation. | > | > This issue is mentioned in ticket:11714#comment:1. | > | > * I believe there were a few other testcases that failed in similar | > ways to T11120. | > | > For what it's worth, the Type /~ Constraint issue that I'm currently | > fighting with in carrying out the (->) generalization is also the | > cause of another Typeable bug, #11715, so I think this is a worthwhile | > thing to sort out. | > | >> Also your text kind of stops... and then repeats itself. | >> | > Oh dear, I apologize for that. Clipboard malfunction. I've included a | > clean version below for reference. | > | >> We could talk at 2pm UK time tomorrow Weds. Richard would you be | free? | >> | > That would work for me. | > | > Cheers, | > | > - Ben | > | > | > | > | > # Background | > | > Consider what happens when we have the coercions, | > | > co1 :: (a ~ b) | > co2 :: (x ~ y) | > | > where | > | > a :: TYPE ra b :: TYPE rb | > x :: TYPE rx y :: TYPE ry | > | > and we want to construct, | > | > co :: (a -> x) ~ (b -> y) | > | > As I understand it this is precisely what Coercion.mkFunCo does. | > Specifically, co should be a TyConAppCo of (->) applied to co1, co2, | > and coercions showing the equalities ra~rx and rb~ry, | > | > (->) (co_ax :: ra ~ rx) (co_by :: rb ~ ry) co1 co2 | > | > Actually implementing mkFunCo to this specification seems to be not | > too difficult, | > | > -- | Build a function 'Coercion' from two other 'Coercion's. That | is, | > -- given @co1 :: a ~ b@ and @co2 :: x ~ y@ produce @co :: (a -> x) | > ~ (b -> y)@. | > mkFunCo :: Role -> Coercion -> Coercion -> Coercion | > mkFunCo r co1 co2 = | > mkTyConAppCo r funTyCon | > [ mkRuntimeRepCo r co1 -- ra ~ rx where a :: TYPE ra, x :: TYPE | > rx | > , mkRuntimeRepCo r co2 -- rb ~ ry where b :: TYPE rb, y :: TYPE | > ry | > , co1 -- a ~ x | > , co2 -- b ~ y | > ] | > | > -- | For a constraint @co :: (a :: TYPE rep1) ~ (b :: TYPE rep2)@ | > produce | > -- @co' :: rep1 ~ rep2@. | > mkRuntimeRepCo :: Role -> Coercion -> Coercion | > mkRuntimeRepCo r co = mkNthCoRole r 0 $ mkKindCo co | > | Just (tycon, [co]) <- splitTyConAppCo_maybe $ mkKindCo co | > = co | > | otherwise | > = pprPanic "mkRuntimeRepCo: Non-TYPE" (ppr co) | > | > So far, so good (hopefully). | > | > # The Problem | > | > Consider what happens when one of the types is, e.g., HasCallStack. | > For the sake of argument let's say | > | > co1 = <HasCallStack>_R | > co2 = <Int>_R | > | > Recall that HasCallStack is, | > | > type HasCallStack = ((?callStack :: CallStack) :: Constraint) | > | > The problem arises when we attempt to evaluate | > | > mkFunCo r co1 co2 | > | > which will look at the kind coercion of co1, | > | > mkKindCo co1 === <Constraint>_R | > | > and then attempt to splitTyConAppCo it, under the assumption that the | > kind coercion is an application of TYPE, from which we can extract the | > RuntimeRep coercion. Instead we find a nullary TyConAppCo of | > Constraint; things then blow up. | > | > This is the problem. | > | > Ultimately it seems all of this is due to the fact that we play it | > fast- and-loose with Type and Constraint in Core (#11715), especially | > with implicit parameters. I worry that resolving this is more than I | > have time to chew on before 8.2.

3 6