October 2021 - ghc-devs

Temporary Outage
by Ben Gamari 08 Oct '21

08 Oct '21

Hi all, You may notice that currently there are numerous CI failures due to apparent network issues. This appears to be due to a network outage on the part of our hosting providing. Further updates are available from Packet [1]. Hopefully the issue will be resolved within the next few hours. Cheers, - Ben [1] https://status.equinixmetal.com/

1 0

Perf backtrace support.
by Andreas Klebinger 07 Oct '21

07 Oct '21

Hello Devs, as some of you know I've recently been working on #8272. The goal being to use the machine stack register for the STG stack as a means to get perf backtraces. I've succeeded in making a branch that works for the first part but have so far been unable to get perf to generate proper back traces. For various reasons I will stop looking at that particular issue. So if anyone feels interested in figuring out where the interaction between our dwarf info and perf unwinding the stack goes wrong please take a look! There is more information on the ticket. Cheers Andreas

1 0

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

06 Oct '21

INTERNAL I see. That will be a bit more involved to try out, because I don't have a ModGuts at hand -- I only have the ModDetails, and the collected CoreProgram from the whole program. But it seems `specProgram` only really uses the rules and the binds from the `ModGuts`, so I should be all right. But one thing I can easily try is just printing the UsageDetails as returned by the specBinds part of specProgram, and that seems empty. So if the actual work of specProgram happens by generating rules in specImports, how will specImports know what rules to generate, from an empty UsageDetails? -----Original Message----- From: Matthew Pickering <matthewtpickering(a)gmail.com> Sent: Wednesday, October 6, 2021 4:24 PM To: Erdi, Gergo <Gergo.Erdi(a)sc.com> Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com>; GHC <ghc-devs(a)haskell.org> Subject: [External] Re: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) I think you need to run at least one simplifier pass as the specialisations are applied via rules (created by specProgram). 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.

1 0

GHC indecisive whether matching on GADT constructors in arrow notation is allowed
by Alexis King 06 Oct '21

06 Oct '21

Hi, I’ve been working on bringing my reimplementation of arrow notation back up to date, and I’ve run into some confusion about the extent to which arrow notation is “supposed” to support matching on GADT constructors. Note [Arrows and patterns] in GHC.Tc.Gen.Pat suggests they aren’t supposed to be supported at all, which is what I would essentially expect. But issues #17423 <https://gitlab.haskell.org/ghc/ghc/-/issues/17423> and #18950 <https://gitlab.haskell.org/ghc/ghc/-/issues/18950> provide examples of using GADT constructors in arrow notation, and there seems to be some expectation that in fact they *ought* to be supported, and some recently-added test cases verify that’s the case. But this is quite odd, because it means the arrows test suite now includes test cases that verify both that this is supported *and* that it isn’t… and all of them pass! Here’s my understanding of the status quo: - Matching on constructors that bind bona fide existential variables is not allowed, and this is verified by the arrowfail004 test case, which involves the following program: data T = forall a. T a panic :: (Arrow arrow) => arrow T T panic = proc (T x) -> do returnA -< T x This program is rejected with the following error message: arrowfail004.hs:12:15: Proc patterns cannot use existential or GADT data constructors In the pattern: T x - Despite the previous point, matching on constructors that bind evidence is allowed. This is enshrined in test cases T15175, T17423, and T18950, which match on constructors like these: data DecoType a where DecoBool :: Maybe (String, String) -> Maybe (Int, Int) -> DecoType Bool data Point a where Point :: RealFloat a => a -> Point a This seems rather contradictory to me. I don’t think there’s much of a meaningful distinction between these types of matches, as they create precisely the same set of challenges from the Core point of view… right? And even if I’m wrong, the error message in arrowfail004 seems rather misleading, since I would definitely call DecoBool and Point above “GADT data constructors”. So what’s the intended story here? Is matching on GADT constructors in arrow notation supposed to be allowed or not? (I suspect this is really just yet another case of “nobody really knows what’s ‘supposed’ to happen with arrow notation,” but I figured I might as well ask out of hopefulness that someone has some idea.) Thanks, Alexis

3 3

Arrow notation, existentials, and TcType demotion
by Alexis King 05 Oct '21

05 Oct '21

Hello, As I mentioned in a previous email <https://mail.haskell.org/pipermail/ghc-devs/2021-October/020223.html>, GHC seems currently somewhat uncertain about whether or not matching on GADTs is permitted in arrow notation. Sam Derbyshire suggested on Twitter <https://twitter.com/samderbyshire/status/1444705156583641099> that we probably do, ideally speaking, want to support them. Unfortunately, I am confident that the existing implementation is *not* up to this task, as I have now demonstrated in issues #20469 <https://gitlab.haskell.org/ghc/ghc/-/issues/20469> and #20470 <https://gitlab.haskell.org/ghc/ghc/-/issues/20470>. The latter of those two issues is particularly challenging to solve, as it highlights the sorts of tricky interactions that can arise when arrow notation is mixed with existential quantification. To give an example, suppose we have the following datatypes: data A where A :: a -> B a -> A data B a where B :: B () And suppose we have the following proc expression: proc a -> case a of A x B -> id -< x The match on the A constructor introduces a locally-scoped skolem, and even though the use of id appears on the RHS, it is *not* actually within the match’s scope—rather, its scope is that of the overall proc expression. This makes it tricky to maintain typechecker invariants, as introduced metavariables must not accidentally leak into the outer scope via these strangely-scoped expressions. For example, when typechecking the above expression, we’ll increment tcl_tclevel before typechecking the id -< x command, and we may introduce fresh metavariables while doing so. This means we may end up with an expected type for id that looks like this: a1[tau:1] -> a2[tau:1] However, when we actually check id against that type, we must do so in a context where tcl_tclevel is 0, not 1. This violates WantedInv from Note [TcLevel invariants] in GHC.Tc.Utils.TcType. This means we need to do a three-step process to properly check id’s type: 1. Synthesize a new metavariable a3[tau:0]. 2. Emit [W] a3[tau:0] ~ (a1[tau:1] -> a2[tau:1]) within the arrow scope, i.e. where tcl_tclevel = 1. 3. Check id against a3[tau:0]. Discerning readers may note that this looks *awfully* similar to the process by which we promote a type via promoteTcType, as described in Note [Promoting a type] in GHC.Tc.Utils.TcMType. However, in this case, we aren’t really promoting a type, but *demoting* it—we ultimately want to decrease its level, not increase it. However, it seems to me that the process of doing this demotion is in fact handled perfectly fine by promoteTcType. So my question is twofold: 1. Is my reasoning about what to do here correct? 2. Is there any harm in using promoteTcType to do this demotion? Thanks, Alexis

1 0

Instantiation of overloaded definition *in Core*
by Erdi, Gergo 04 Oct '21

04 Oct '21

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.

2 1

Optics?
by Alan & Kim Zimmerman 04 Oct '21

04 Oct '21

Hi all I am working on a variant of the exact printer which updates the annotation locations from the `EpaSpan` version to the `EpaDelta` version, as the printing happens data EpaLocation = EpaSpan RealSrcSpan | EpaDelta DeltaPos The function doing the work is this markAnnKw :: (Monad m, Monoid w) => EpAnn a -> (a -> EpaLocation) -> (a -> EpaLocation -> a) -> AnnKeywordId -> EP w m (EpAnn a) which gets an annotation, a function to pull a specific location out, and one to update it. I do not know much about lenses, but have a feeling that I could simplify things by using one. Can anyone give me any pointers? Alan

3 3

Prettyprinting GHC.Stg.Syntax.StgOp
by Norman Ramsey 03 Oct '21

03 Oct '21

Type StgOp and its constructors are exported from module GHC.Stg.Syntax. But the prettyprinting function pprStgOp is not exported. I'm thinking of exporting the function and also of defining an instance of Outputable. Is there any reason not to? If this sounds OK to people, I'll make a PR. Norman

2 1

Stack lock issue
by Dominick Samperi 02 Oct '21

02 Oct '21

Hi, Stack install does its thing in some hashed directory under .stack-work by default, but I want to write to <package-root>/bin as part of the configure process. I'm trying to do this as follows: -- configure file contains: cd $(stack path --project-root) echo "..." > .bin/foo.sh cd - > cd <project-root> > stack install I'm doing this under Windows with the born shell in my path. Problem: the use of stack to find the project-root directory is blocked waiting for the outer stack to terminate! This may have something to do with Windows "Device or resource busy" lock. Is there a better way? Thanks, Dominick <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0