October 2021 - ghc-devs

Re: To allow deriving poly-kinded Generic1 instances
by Ryan Scott 13 Oct '21

13 Oct '21

Thanks for posting an example—that's very helpful to figure out what is going on. > Currently, GHC rejects the following code: > > {-# LANGUAGE DeriveGeneric #-} > {-# LANGUAGE PolyKinds #-} > import GHC.Generics > > data HKD f = Foo (f Int) (f Double) > | Bar (f Bool) > deriving Generic1 > The compilation error is > > • Can't make a derived instance of ‘Generic1 HKD’: > Constructor ‘Foo’ applies a type to an argument involving the last parameter > but the applied type is not of kind * -> *, and > Constructor ‘Foo’ applies a type to an argument involving the last parameter > but the applied type is not of kind * -> *, and > Constructor ‘Bar’ applies a type to an argument involving the last parameter > but the applied type is not of kind * -> * > • In the data declaration for ‘HKD’ I see. That error message could be worded better, in my opinion. The issue really isn't so much about the kind of `f`. If you had written `data HKD (f :: Type -> Type) = Baz (Proxy f)`, for instance, I would expect it to work. The real issue is _where_ `f` appears in the data constructors. In `Bar`, for instance, you have: > Bar (f Bool) `Generic1` is limited to data types where the last type parameter only appears as the last type argument in any field. This means that a field like `Proxy f` would be fine, as that would be represented as `Rec1 Proxy` in a `Rep1` instance. `f Bool`, on the other hand, is problematic. `GHC.Generics` doesn't have a representation type that simultaneously allows representing this field while also "focusing" on the last type parameter like `Rec1`, `Par1`, etc. would allow. The `Foo` constructor has similar issues. The error-reporting machinery for `DeriveGeneric` essentially just accumulates every issue it encounters and reports everything at once, which is why there is a duplicate error message involving `Foo`. Needless to say, this kind of error message could be improved. > Although it is possible to define a hand-rolled instance of Generic1 Really? I'm not sure how you would define a correct `Generic1` instance for `HKD` at all. What did you have in mind? Best, Ryan On Wed, Oct 13, 2021 at 8:33 AM Fumiaki Kinoshita <fumiexcel(a)gmail.com> wrote: > Currently, GHC rejects the following code: > > {-# LANGUAGE DeriveGeneric #-} > {-# LANGUAGE PolyKinds #-} > import GHC.Generics > > data HKD f = Foo (f Int) (f Double) > | Bar (f Bool) > deriving Generic1 > > The compilation error is > > • Can't make a derived instance of ‘Generic1 HKD’: > Constructor ‘Foo’ applies a type to an argument involving the last > parameter > but the applied type is not of kind * -> *, and > Constructor ‘Foo’ applies a type to an argument involving the last > parameter > but the applied type is not of kind * -> *, and > Constructor ‘Bar’ applies a type to an argument involving the last > parameter > but the applied type is not of kind * -> * > • In the data declaration for ‘HKD’ > | > 7 | deriving Generic1 > > Although it is possible to define a hand-rolled instance of Generic1, > DeriveGeneric is still restricted to Type -> Type. > > 2021年10月13日(水) 21:17 Ryan Scott <ryan.gl.scott(a)gmail.com>: > >> Hello, >> >> I'm not quite sure I understand the issue you're hitting. Generic1 is >> poly-kinded, so I would expect it to be able to handle data types where the >> last type parameter has differing kinds. Can you post a complete example of >> the program you expect to typecheck, but doesn't? >> >> Best, >> >> Ryan >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >

1 0

Re: To allow deriving poly-kinded Generic1 instances
by Ryan Scott 13 Oct '21

13 Oct '21

Hello, I'm not quite sure I understand the issue you're hitting. Generic1 is poly-kinded, so I would expect it to be able to handle data types where the last type parameter has differing kinds. Can you post a complete example of the program you expect to typecheck, but doesn't? Best, Ryan

1 0

GitLab summary note on review
by Richard Eisenberg 12 Oct '21

12 Oct '21

Hi devs, I've frequently wanted to attach a summary note to a review, unattached to any line of code. I thought this was impossible, but I see how to do it now. After making your review, with perhaps many line comments, go back to the Overview pane. Then, you can write a comment at the bottom, and, critically, add it to the review. Then, when you submit the review, the summary comment goes with it. Happy reviewing, Richard

2 1

how does a CAF become unreachable?
by Norman Ramsey 12 Oct '21

12 Oct '21

I spent the afternoon spelunking through some code and the Commentary, and I'm wondering how a CAF becomes unreachable. I gather it might have to do with GHC floating a static expression out of a context until it becomes a CAF, but I'm still not seeing how a CAF could at one point be reachable, then dynamically become unreachable. Can anyone show an example? Norman

2 1

where to go for HLS details?
by Norman Ramsey 12 Oct '21

12 Oct '21

Where is the place to go to talk details of the Haskell Language Server? I'm using the HLS with the GHC I have compiled from HEAD, and I am sitting on a number of difficulties: - When a project is compiled against a Stage 1 `base` library (as opposed to the one shipped with the bootstrap compiler), I am not always getting the documentation I expect. - The HLint part of the HLS seems to struggle finding modules in nested directories. - I cannot seem to get the `hiedb` command to index any files. - I'd like to set up the HLS to get to documentation via an HTTP-ish URL rather than the file:// URL that it is currently using, so that `doc-index.json` can be loaded successfully. I'm not quite ready to open a Github issue for any of these troubles just yet, but I'm not sure I can make progress on my own. Where is a good place to go for help? Norman

4 5

To allow deriving poly-kinded Generic1 instances
by Fumiaki Kinoshita 12 Oct '21

12 Oct '21

I was hacking GHC to see if it's able to derive Generic1 instance for datatypes with kind (Type -> Type) -> Type by omitting some checks. I noticed that the type parameter is substituted by GHC.Types.Any, preventing higher-kinded instances from typechecking. I found a comment implying that this is intentional; in GHC.Tc.Deriv.Generic.hs:977, Alternatively, we could have avoided this problem by expanding all type synonyms on the RHSes of Rep1 instances. But we might blow up the size of these types even further by doing this, so we choose not to do so. It wasn't obvious to me if binding a parameter in the type synonym instance declaration of Rep1 cause problems, because that's what I'd do if I were to define an instance by hand. Is there any offending example? I'm also trying to make such change myself (it doesn't add a type parameter and I'm not sure why) https://gitlab.haskell.org/fumieval/ghc/-/commit/bfe7766af80d90590b6b032d18…

1 0

help validating a modified compiler?
by Norman Ramsey 12 Oct '21

12 Oct '21

I've made a minor change to GHC, and before submitting a PR, I'd like to validate the change. But I don't really know how to interpret the output of the `validate` script. Mine runs for about 40 minutes and then ends in an error: # We are installing wrappers to programs by searching corresponding # wrappers. If wrapper is not found, we are attaching the common wrapper # to it. This implementation is a bit hacky and depends on consistency # of program names. For hadrian build this will work as programs have a # consistent naming procedure. if [ -L wrappers/ghc ]; then echo "ghc is a symlink"; fi ghc is a symlink cp: target 'dir/bin/ghc' is not a directory make: *** [Makefile:197: install_wrappers] Error 1 ________________________________________________________ Executed in 39.60 mins fish external usr time 146.65 mins 0.00 millis 146.65 mins sys time 9.55 mins 1.60 millis 9.55 mins I'm in the process of trying `validate` on a fresh checkout, but at 40 minutes per shot, I feel like I might be on the wrong track. Should I just create a merge request and rely on CI for the validation? Or do something else? Norman

3 3

-O* does more than what's in optLevelFlags?
by Erdi, Gergo 11 Oct '21

11 Oct '21

PUBLIC What is set by -O* that is not included in optLevelFlags? I would have thought that setting all the flags implied by, e.g., -O1, would be the same as setting -O1 itself. But this is not the case! Here are all the flags for O1 from optLevelFlags: Opt_DoLambdaEtaExpansion Opt_DoEtaReduction Opt_LlvmTBAA Opt_CallArity Opt_Exitification Opt_CaseMerge Opt_CaseFolding Opt_CmmElimCommonBlocks Opt_CmmSink Opt_CmmStaticPred Opt_CSE Opt_StgCSE Opt_EnableRewriteRules Opt_FloatIn Opt_FullLaziness Opt_IgnoreAsserts Opt_Loopification Opt_CfgBlocklayout Opt_Specialise Opt_CrossModuleSpecialise Opt_InlineGenerics Opt_Strictness Opt_UnboxSmallStrictFields Opt_CprAnal Opt_WorkerWrapper Opt_SolveConstantDicts Opt_NumConstantFolding And here are the ones that are set by O0 (the default) but not by O1: Opt_IgnoreInterfacePragmas Opt_OmitInterfacePragmas So I expected that the following two invocations of GHC would be equivalent: 1. ghc -O1 2. ghc -fdo-lambda-eta-expansion -fdo-eta-reduction -fllvm-tbaa -fcall-arity -fexitification -fcase-merge -fcase-folding -fcmm-elim-common-blocks -fcmm-sink -fcmm-static-pred -fcse -fstg-cse -fenable-rewrite-rules -ffloat-in -ffull-laziness -fignore-asserts -floopification -fblock-layout-cfg -fspecialise -fcross-module-specialise -finline-generics -fstrictness -funbox-small-strict-fields -fcpr-anal -fworker-wrapper -fsolve-constant-dicts -fnum-constant-folding -fno-ignore-interface-pragmas -fno-omit-interface-pragmas However, just by observing the output of -dshow-passes, I can see that while -O1 applies all these optimizations, the second version does NOT, even though I have turned on each and every one of them one by one. Looking at compiler/GHC/Driver/Session.hs, it is not at all clear that -O* should do more than just setting the flags from optLevelFlags. What other flags are implied by -O*? This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

3 6

Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*)
by Erdi, Gergo 11 Oct '21

11 Oct '21

PUBLIC PUBLIC Hi, Thanks! Originally I was going to reply to this saying that my transformation isn't running in CoreM so where do I get that environment from, but then I realized I can just build it from the md_insts field of ModDetails. However, after thinking more about it, I also realized that I shouldn't ever really need to conjure up dictionaries from thin air: the whole reason I am making a specific specialization of an overloaded function is because I found somewhere a call at that type. But then, that call also gives me the dictionary! Of course at this point, this sounds exactly like what GHC already does in `specProgram`. So maybe I should be able to just use that? Unfortunately, my initial testing seems to show that even if I run `specBind` manually on my whole-program collected CoreProgram, it doesn't do the work I would expect from it! In the following example, I have only kept the definitions that are relevant. Before specialisation, I have the following whole-program Core: (>>=) :: forall (m :: * -> *) a b. Monad m => m a -> (a -> m b) -> m b [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=<S(LSL),U(A,U,A)>] (>>=) = \ (@(m :: * -> *)) (v_sGm [Occ=Once1!] :: Monad m) -> case v_sGm of { C:Monad _ [Occ=Dead] v_sGp [Occ=Once1] _ [Occ=Dead] -> v_sGp } $dm>> :: forall (m :: * -> *) a b. Monad m => m a -> m b -> m b [GblId, Arity=3, Unf=OtherCon []] $dm>> = \ (@(m :: * -> *)) ($dMonad [Occ=Once1] :: Monad m) (@a) (@b) (ma [Occ=Once1] :: m a) (mb [Occ=OnceL1] :: m b) -> let { sat_sGQ [Occ=Once1] :: a -> m b [LclId] sat_sGQ = \ _ [Occ=Dead] -> mb } in >>= @m $dMonad @a @b ma sat_sGQ C:Monad [InlPrag=NOUSERINLINE CONLIKE] :: forall (m :: * -> *). Applicative m -> (forall a b. m a -> (a -> m b) -> m b) -> (forall a b. m a -> m b -> m b) -> Monad m [GblId[DataCon], Arity=3, Caf=NoCafRefs, Cpr=m1, Unf=OtherCon []] C:Monad = \ (@(m :: * -> *)) (eta_B0 [Occ=Once1] :: Applicative m) (eta_B1 [Occ=Once1] :: forall a b. m a -> (a -> m b) -> m b) (eta_B2 [Occ=Once1] :: forall a b. m a -> m b -> m b) -> C:Monad @m eta_B0 eta_B1 eta_B2 $fMonadIO [InlPrag=NOUSERINLINE CONLIKE] :: Monad IO [GblId[DFunId]] $fMonadIO = C:Monad @IO $fApplicativeIO bindIO $fMonadIO_$c>>; $fMonadIO_$c>> [Occ=LoopBreaker] :: forall a b. IO a -> IO b -> IO b [GblId] $fMonadIO_$c>> = \ (@a) (@b) -> $dm>> @IO $fMonadIO @a @b; sat_sHr :: IO () [LclId] sat_sHr = returnIO @() () sat_sHq :: IO () [LclId] sat_sHq = returnIO @() () main :: IO () [GblId] main = $fMonadIO_$c>> @() @() sat_sHq sat_sHr Now I pass this to GHC's `specBind`, but the output is exactly the same as the input! (or it's close enough that I can't spot the difference). (>>=) :: forall (m :: * -> *) a b. Monad m => m a -> (a -> m b) -> m b [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=<S(LSL),U(A,U,A)>] (>>=) = \ (@(m :: * -> *)) (v_sGm [Occ=Once1!] :: Monad m) -> case v_sGm of { C:Monad _ [Occ=Dead] v_sGp [Occ=Once1] _ [Occ=Dead] -> v_sGp } $dm>> :: forall (m :: * -> *) a b. Monad m => m a -> m b -> m b [GblId, Arity=3, Unf=OtherCon []] $dm>> = \ (@(m :: * -> *)) ($dMonad [Occ=Once1] :: Monad m) (@a) (@b) (ma [Occ=Once1] :: m a) (mb [Occ=OnceL1] :: m b) -> let { sat_MHt [Occ=Once1] :: a -> m b [LclId] sat_MHt = \ _ [Occ=Dead] -> mb } in >>= @m $dMonad @a @b ma sat_MHt C:Monad [InlPrag=NOUSERINLINE CONLIKE] :: forall (m :: * -> *). Applicative m -> (forall a b. m a -> (a -> m b) -> m b) -> (forall a b. m a -> m b -> m b) -> Monad m [GblId[DataCon], Arity=3, Caf=NoCafRefs, Cpr=m1, Unf=OtherCon []] C:Monad = \ (@(m :: * -> *)) (eta_B0 [Occ=Once1] :: Applicative m) (eta_B1 [Occ=Once1] :: forall a b. m a -> (a -> m b) -> m b) (eta_B2 [Occ=Once1] :: forall a b. m a -> m b -> m b) -> C:Monad @m eta_B0 eta_B1 eta_B2 $fMonadIO [InlPrag=NOUSERINLINE CONLIKE] :: Monad IO [GblId[DFunId]] $fMonadIO = C:Monad @IO $fApplicativeIO bindIO $fMonadIO_$c>>; $fMonadIO_$c>> [Occ=LoopBreaker] :: forall a b. IO a -> IO b -> IO b [GblId] $fMonadIO_$c>> = \ (@a) (@b) -> $dm>> @IO $fMonadIO @a @b; sat_sHr :: IO () [LclId] sat_sHr = returnIO @() () sat_sHq :: IO () [LclId] sat_sHq = returnIO @() () main :: IO () [GblId] main = $fMonadIO_$c>> @() @() sat_sHq sat_sHr Why is that? I would have expected that the call chain main >-> $fMonadIO_$c>> >-> $dm>> would have resulted in a specialization along the lines of: $dm>>_IO :: forall a b. IO a -> IO b -> IO b >>=_IO :: forall a b. IO a -> (a -> IO b) -> IO b With appropriate definitions that can then be simplified away. But none of this seems to happen -- $dm>> doesn't get an IO-specific version, and so $fMonadIO_$c>> still ends up with a dictionary-passing call to $dm>>. Isn't this exactly the situation that the specialiser is supposed to eliminate? Thanks, Gergo From: Simon Peyton Jones <simonpj(a)microsoft.com> Sent: Monday, October 4, 2021 7:29 PM To: Erdi, Gergo <Gergo.Erdi(a)sc.com> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com>; GHC <ghc-devs(a)haskell.org> Subject: [External] RE: Instantiation of overloaded definition *in Core* PUBLIC You can look it up in the class instance environment, which the Simplifier does have access to it. That's relatively easy when you have a simple dictionary like (Monad IO). But if you want (Eq [Int]) you first of all have to look up the (Eq [a]) dictionary, then the Eq Int dictionary, and apply the former to the latter. We don't (yet) have a simple API to do that, although it would not be hard to create one. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj(a)microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones(a)gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>.) From: ghc-devs <ghc-devs-bounces(a)haskell.org<mailto:ghc-devs-bounces@haskell.org>> On Behalf Of Erdi, Gergo via ghc-devs Sent: 04 October 2021 10:30 To: 'GHC' <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com<mailto:Raphael.Montelatici@sc.com>> Subject: Instantiation of overloaded definition *in Core* PUBLIC Hi, I'd like to instantiate Core definitions. For example, suppose I have the following Core definition: foo :: forall m a b. Monad m => m a -> m b -> m b foo = \ @m ($d :: Monad m) @a @b (ma :: m a) (mb :: m b) -> ... Now let's say I'd like to instantiate it for m ~ IO. It is quite straightforward to go from the above to: foo_IO_0 :: forall a b. Monad IO => IO a -> IO b -> IO b foo_IO_0 = \ ($d :: Monad IO) @a @b (ma :: IO a) (mb :: IO b) -> ... However, I would like to go all the way to: foo_IO :: forall a b. IO a -> IO b -> IO b foo_IO = \ @a @b (ma :: IO a) (mb :: IO b) -> ... Because instances are coherent, it should be sound to replace all occurrences of $d with "the" dictionary for Monad IO. However, the places I've found for this kind of query seem to live in the typechecker. How do I access this information while working with Core? Thanks, Gergo This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

3 6

Why can't arguments be levity polymorphic for inline functions?
by Clinton Mead 08 Oct '21

08 Oct '21

Hi All Not sure if this belongs in ghc-users or ghc-devs, but it seemed devy enough to put it here. Section 6.4.12.1 <https://downloads.haskell.org/~ghc/9.0.1/docs/html/users_guide/exts/levity_…> of the GHC user manual points out, if we allowed levity polymorphic arguments, then we would have no way to compile these functions, because the code required for different levites is different. However, if such a function is {-# INLINE #-} or {-# INLINABLE #-} there's no need to compile it as it's full definition is in the interface file. Callers can just compile it themselves with the levity they require. Indeed callers of inline functions already compile their own versions even without levity polymorphism (for example, presumably inlining function calls that are known at compile time). The only sticking point to this that I could find was that GHC will only inline the function if it is fully applied <https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/pragmas.…>, which suggests that the possibility of partial application means we can't inline and hence need a compiled version of the code. But this seems like a silly restriction, as we have the full RHS of the definition in the interface file. The caller can easily create and compile it's own partially applied version. It should be able to do this regardless of levity. It seems to me we're okay as long as the following three things aren't true simultaneously: 1. Blah has levity polymorphic arguments 2. Blah is exported 3. Blah is not inline If a function "Blah" is not exported, we shouldn't care about levity polymorphic arguments, because we have it's RHS on hand in the current module and compile it as appropriate. And if it's inline, we're exposing it's full RHS to other callers so we're still fine also. Only when these three conditions combine should we give an error, say like: "Blah has levity polymorphic arguments, is exported, and is not inline. Please either remove levity polymorphic arguments, not export it or add an {-# INLINE #-} or {-# INLINABLE #-} pragma. I presume however there are some added complications that I don't understand, and I'm very interested in what they are as I presume they'll be quite interesting. Thanks, Clinton

7 10