From Gergo.Erdi at sc.com Mon Oct 3 07:08:48 2022 From: Gergo.Erdi at sc.com (Erdi, Gergo) Date: Mon, 3 Oct 2022 07:08:48 +0000 Subject: Looking up names in an "opportunistic" type checker plugin Message-ID: PUBLIC Hi, I'm writing a type checker plugin that should do things whenever used in the context of a module that already has some definitions loaded. I've hacked together the following function using internal details that I feel I should not be using: lookupOrigMaybe :: Module -> OccName -> TcPluginM (Maybe Name) lookupOrigMaybe mod occ = do hsc_env <- getTopEnv unsafeTcPluginTcM $ liftIO $ updateNameCache (hsc_NC hsc_env) mod occ $ \cache0 -> do let name = lookupOrigNameCache cache0 mod occ return (cache0, name) I would like to do this in a nicer way instead. It should be enough to check that the given module is already loaded, since for my use case, if the module is there but the name isn't, then all bets are off and my plugin might as well just error out. So I was hoping I could use `findImportedModule` followed by `lookupOrig`, but alas, `findImportedModule` fails me in one of two ways: 1. If I don't specify the package (i.e. use `NoPkgQual`), `findImportedModule` seems to return a `Found{}` result even when the module isn't actually loaded yet, leading to `lookupOrig` failing: attempting to use module 'main:Cortex.Stem.Relation.Types' (Cortex.Stem.Relation.Types) which is not loaded 1. If I do specify the package (using `ThisPkg`), then `findImportedModule` chokes in situations when the given unit would come "later" in the dependency graph than the currenty processed one: ghc-mu-core-to-exp: panic! (the 'impossible' happened) GHC version 9.5.20220830: findImportModule Cortex.Stem.Relation.Types "main" Just ghc-bignum main [ghc-bignum, cortex-prim] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/GHC/Utils/Panic.hs:188:37 in ghc-lib-0.20220830-FvKByKwp6ri5ICk6wiQO8W:GHC.Utils.Panic pprPanic, called at compiler/GHC/Unit/Finder.hs:160:32 in ghc-lib-0.20220830-FvKByKwp6ri5ICk6wiQO8W:GHC.Unit.Finder Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug So my question then, is what is the recommended way of looking up a loaded definition opportunistically from a type checker plugin? 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Oct 6 12:28:50 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 06 Oct 2022 14:28:50 +0200 Subject: Request for Nominations to the GHC Steering Committee Message-ID: Dear Haskell community, the GHC Steering committee is seeking nominations for one or more new members. The committee scrutinizes, nitpicks, improves, weighs and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. In particular, please have a look at the bylaws at https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to maintain in perpetuity in GHC's code base, to learn, and to deal with its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore seek a balance of background, expertise, and views on the committee. Membership of the committee gives you the chance to influence the future direction of Haskell, and to serve the Haskell community. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. To nominate yourself, please send an email to me (as the committee secretary) at mail at joachim-breitner.de until February 11th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. On behalf of the committee, Joachim Breitner -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Thu Oct 6 12:31:54 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 06 Oct 2022 14:31:54 +0200 Subject: Request for Nominations to the GHC Steering Committee In-Reply-To: References: Message-ID: Sorry for that, but Am Donnerstag, dem 06.10.2022 um 14:28 +0200 schrieb Joachim Breitner: > To nominate yourself, please send an email to me (as the committee > secretary) at mail at joachim-breitner.de until February 11th. > should be October 16th. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From matthewtpickering at gmail.com Tue Oct 11 11:01:16 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 11 Oct 2022 12:01:16 +0100 Subject: Implementing a compilation server In-Reply-To: References: Message-ID: Sorry Facundo I didn't realise this reply had remaining questions in it. On Mon, May 30, 2022 at 3:35 AM Domínguez, Facundo wrote: > > Thanks Matthew for your pointers. > > Since originally posting, I managed to simplify the problem by terminating the compilation server at the end of a build, which allows to introduce the assumption that the code doesn't change during the lifetime of the server. > > Now, I'm observing that sometimes different compilation requests place the same package databases at different paths using the -package-db flags. From the point of view of GHC, it is as if the package databases had been moved from one location to another. In newer requests, GHC still looks for the interface files at the old locations, and fails when it doesn't find them. I think you mean that your build system is putting the package database at different paths. If you modify the package database arguments at all you need to call `setSessionDynFlags` to update the state of the package databases again. You might also need to clear the finder cache if by "package database" you also mean the location of the interface files. > > Another difference between requests is that, even for a same package database, different interface files are present, depending on what the module under compilation imports transitively. This is causing failures sometimes but not always, I still need to pin exactly the circumstances. The error manifests as an attempt to load a missing interface file that is apparently not transitively needed. I don't think I can comment on this without more information. It sounds like you have a missing dependency in your build graph so the right .hi files are not present? Need a reproducer to comment properly. > > If I understand correctly, all the packages pointed with -package-id and -package-db end up in the EPS. And this means that we can't expect to update the locations of the interface files without discarding and repopulating the EPS, correct? I'm thinking of this as approximately as costly as restarting the compilation server. The EPS does not contain "packages" but interface files from packages and the interface files are only loaded if they are needed. Once the interface file is loaded into the EPS I would not expect it to matter where the file came from on disk, as now GHC can just read it from memory. Was there a specific bug you had here? > > I can reasonably ensure that package databases aren't moved around between compilation requests. But from the standpoint of the build system, it would require some compromises to demand that all of the interface files of a package be available even when not all of them are transitively imported. Can we hope to have GHC cope with this dynamic membership of modules to Haskell packages during the build? Is this an ability that 8.10.7 already has? I don't think you need to engineer this requirement. GHC should work fine if you only have the transitive interface files. This is how hadrian now works and also multi-component support in GHC 9.4. I can't comment so much on 8.10.7 as it was a long time ago! Matt > > Thanks, > Facundo > > On Thu, May 5, 2022 at 5:13 AM Matthew Pickering wrote: >> >> Hi Facundo >> >> Some pointers... >> >> 1. Only put things in the EPS if they are not going to change >> throughout the whole compilation >> 2. Treat everything which can change as a home package >> 2a. I suppose you have performed your own dependency analysis, so >> build your own `ModGraph` and start looking from `load'`, you might >> just want to call `upsweep_mod/compileOne'` directly yourself. >> 2b. I suppose you are NOT targeting 9.4.1 yet, but that will make >> things easier as you can use support for multiple home packages, >> otherwise you will get into severe difficulties if you load a package >> you later want to compile into the EPS. The only thing you can do here >> is restart the compilation session I think. >> 3. To my knowledge, there is no issue using different -this-unit-id in >> the same session. Not sure what errors you have seen. >> 4. You need to use --make mode rather than -c (oneshot) because >> oneshot mode loads all interfaces into the EPS (see point 1) >> >> ghcide is the closest program to this kind of compilation server you >> imagine so you can look at how that uses the GHC API. >> >> Cheers, >> >> Matt >> >> >> On Thu, May 5, 2022 at 1:06 AM Domínguez, Facundo >> wrote: >> > >> > Dear ghc devs, >> > >> > I'm using the ghc API to write a compilation server (a.k.a. persistent worker). The idea is to serve requests to compile individual modules. In this fashion, we can compile modules with different compilation flags and yet pay only once for the startup overheads of the compiler. >> > >> > One challenge of this approach is to reuse as much as possible from the ghc API session/environment from one compilation request to the next, so we save the trouble of reconstructing it each time. This message is to ask for advise on how to better accomplish this reuse. >> > >> > I tried reusing the whole environment for multiple requests, but I'm conjecturing that this might cause troubles when the requests require building modules with different values of -this-unit-id. Another problem that streams from this is that recompiling a module which defines a type class instance fails because it encounters in the environment the type class instance from the >> > previous compilation. >> > >> > My work-in-progress implementation is here [1]. There appears to be multiple ways to compile a module in the API, so far I have been trying DriverPipeline.compileFile. >> > >> > My best lead right now is to look for inspiration in how GHCi implements the load command, but this does a sort of --make compilation while I'm going here for the one-shot style. >> > >> > Thanks in advance, >> > Facundo >> > >> > [1] https://github.com/tweag/rules_haskell/blob/16ba422457ea4daa5dbf40d46327ebcb20588e97/tools/haskell_module_worker/src/Compile.hs#L188 >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Tue Oct 11 18:15:02 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 11 Oct 2022 14:15:02 -0400 Subject: Warnings in RTS In-Reply-To: References: Message-ID: <8735bugrdq.fsf@smart-cactus.org> Simon Peyton Jones writes: > Whenever I compile the RTS I get these warnings. Are they necessary? > Indeed they aren't and I doubt that inlining of these is even beneficial. I have opened #22280 to track this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ianwookim at gmail.com Tue Oct 11 23:46:34 2022 From: ianwookim at gmail.com (Ian-Woo Kim) Date: Tue, 11 Oct 2022 16:46:34 -0700 Subject: Serious bug in GHC 9.4 on basic math on aarch64 Message-ID: Hi, We found a reproducible error with a simple math test (div/mod) on aarch64. (on linux, on macos), so we want to call for attention on this. https://gitlab.haskell.org/ghc/ghc/-/issues/22282 This was originally caught by this issue: https://github.com/haskell-foundation/foundation/issues/571 Thank you! Ian-Woo Kim Mercury Technologies From matthewtpickering at gmail.com Wed Oct 12 11:12:55 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 12 Oct 2022 12:12:55 +0100 Subject: Serious bug in GHC 9.4 on basic math on aarch64 In-Reply-To: References: Message-ID: Thank you for bringing this bug to our attention Ian, we have triaged it as highest priority and will include a fix in the next release in the 9.4 series. Cheers, Matt On Wed, Oct 12, 2022 at 12:46 AM Ian-Woo Kim wrote: > > Hi, > > We found a reproducible error with a simple math test (div/mod) on > aarch64. (on linux, on macos), so we want to call for attention on > this. > https://gitlab.haskell.org/ghc/ghc/-/issues/22282 > This was originally caught by this issue: > https://github.com/haskell-foundation/foundation/issues/571 > > Thank you! > > Ian-Woo Kim > Mercury Technologies > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simon.jakobi at googlemail.com Wed Oct 12 11:19:40 2022 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Wed, 12 Oct 2022 13:19:40 +0200 Subject: Serious bug in GHC 9.4 on basic math on aarch64 In-Reply-To: References: Message-ID: I've spread your message on r/haskell and Discourse: * https://www.reddit.com/r/haskell/comments/y215qi/serious_bug_in_ghc_94_on_basic_math_on_aarch64 * https://discourse.haskell.org/t/serious-bug-in-ghc-9-4-on-basic-math-on-aarch64/5167 Am Mi., 12. Okt. 2022 um 01:46 Uhr schrieb Ian-Woo Kim : > Hi, > > We found a reproducible error with a simple math test (div/mod) on > aarch64. (on linux, on macos), so we want to call for attention on > this. > https://gitlab.haskell.org/ghc/ghc/-/issues/22282 > This was originally caught by this issue: > https://github.com/haskell-foundation/foundation/issues/571 > > Thank you! > > Ian-Woo Kim > Mercury Technologies > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Wed Oct 12 23:20:43 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 12 Oct 2022 20:20:43 -0300 Subject: Milestones page is missing or has inaccurate dates Message-ID: Hi The Milestones page is missing many dates or has inaccurate dates: - Most milestones don't have any associated completion date. - As far as I know 9.4.2 and 9.2.4 are released but the milestones pages doesn't seem to show that. Can the page be updated so we have an idea of what is coming when? There has been a lot of great work done and I know a lot is being worked on. It would be great if the milestones page could be updated to better reflect that. Thanks George -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Oct 12 23:51:30 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 12 Oct 2022 19:51:30 -0400 Subject: Milestones page is missing or has inaccurate dates In-Reply-To: References: Message-ID: <87wn94fvo2.fsf@smart-cactus.org> George Colpitts writes: > Hi > > The Milestones page is > missing many dates or has inaccurate dates: > > - Most milestones don't have any associated completion date. > - As far as I know 9.4.2 and 9.2.4 are released but the milestones pages > doesn't seem to show that. > > Can the page be updated so we have an idea of what is coming when? > > There has been a lot of great work done and I know a lot is being worked > on. It would be great if the milestones page could be updated to better > reflect that. > I have updated the dates of 9.4.2, 9.4.3, 9.2.4, and 9.6.1. In short, * 9.6.1 is scheduled for some time in January 2023; we plan to fork for this release next month * I am actively working on backports for 9.4.3 as we speak * my colleague Zubin will be working on 9.2.4 next week, hopefully for release the following week * 9.4.2 was released in late August There are quite a few other milestones which lack dates; for the most part these are releases which don't have a formal timeline yet. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From george.colpitts at gmail.com Thu Oct 13 11:56:33 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Thu, 13 Oct 2022 08:56:33 -0300 Subject: Milestones page is missing or has inaccurate dates In-Reply-To: <87wn94fvo2.fsf@smart-cactus.org> References: <87wn94fvo2.fsf@smart-cactus.org> Message-ID: Hi Ben Thanks for the very quick response which addresses my concerns ! However I'm confused by - my colleague Zubin will be working on 9.2.4 next week, hopefully for release the following week Zubin sent mail on July 28th with a subject line of "[Haskell] [ANNOUNCE] GHC 9.2.4 released". I'm running it - $ ghc --version The Glorious Glasgow Haskell Compilation System, version 9.2.4 Thanks again George On Wed, Oct 12, 2022 at 8:51 PM Ben Gamari wrote: > George Colpitts writes: > > > Hi > > > > The Milestones page is > > missing many dates or has inaccurate dates: > > > > - Most milestones don't have any associated completion date. > > - As far as I know 9.4.2 and 9.2.4 are released but the milestones > pages > > doesn't seem to show that. > > > > Can the page be updated so we have an idea of what is coming when? > > > > There has been a lot of great work done and I know a lot is being worked > > on. It would be great if the milestones page could be updated to better > > reflect that. > > > I have updated the dates of 9.4.2, 9.4.3, 9.2.4, and 9.6.1. In short, > > * 9.6.1 is scheduled for some time in January 2023; we plan to fork for > this release next month > > * I am actively working on backports for 9.4.3 as we speak > > * my colleague Zubin will be working on 9.2.4 next week, hopefully for > release the following week > > * 9.4.2 was released in late August > > There are quite a few other milestones which lack dates; for the most > part these are releases which don't have a formal timeline yet. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Oct 13 13:23:33 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 13 Oct 2022 09:23:33 -0400 Subject: Milestones page is missing or has inaccurate dates In-Reply-To: References: <87wn94fvo2.fsf@smart-cactus.org> Message-ID: I think 9.2.4 got released early because of https://gitlab.haskell.org/ghc/ghc/-/issues/21708, and the milestone needs to be updated. On Thu, Oct 13, 2022 at 7:57 AM George Colpitts wrote: > > Hi Ben > > Thanks for the very quick response which addresses my concerns ! However I'm confused by > > my colleague Zubin will be working on 9.2.4 next week, hopefully for > release the following week > > Zubin sent mail on July 28th with a subject line of "[Haskell] [ANNOUNCE] GHC 9.2.4 released". I'm running it > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 9.2.4 > > Thanks again > George > > On Wed, Oct 12, 2022 at 8:51 PM Ben Gamari wrote: >> >> George Colpitts writes: >> >> > Hi >> > >> > The Milestones page is >> > missing many dates or has inaccurate dates: >> > >> > - Most milestones don't have any associated completion date. >> > - As far as I know 9.4.2 and 9.2.4 are released but the milestones pages >> > doesn't seem to show that. >> > >> > Can the page be updated so we have an idea of what is coming when? >> > >> > There has been a lot of great work done and I know a lot is being worked >> > on. It would be great if the milestones page could be updated to better >> > reflect that. >> > >> I have updated the dates of 9.4.2, 9.4.3, 9.2.4, and 9.6.1. In short, >> >> * 9.6.1 is scheduled for some time in January 2023; we plan to fork for >> this release next month >> >> * I am actively working on backports for 9.4.3 as we speak >> >> * my colleague Zubin will be working on 9.2.4 next week, hopefully for >> release the following week >> >> * 9.4.2 was released in late August >> >> There are quite a few other milestones which lack dates; for the most >> part these are releases which don't have a formal timeline yet. >> >> Cheers, >> >> - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- brandon s allbery kf8nh allbery.b at gmail.com From ben at smart-cactus.org Thu Oct 13 13:37:29 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 13 Oct 2022 09:37:29 -0400 Subject: Milestones page is missing or has inaccurate dates In-Reply-To: References: <87wn94fvo2.fsf@smart-cactus.org> Message-ID: <87sfjrg7zv.fsf@smart-cactus.org> George Colpitts writes: > Hi Ben > > Thanks for the very quick response which addresses my concerns ! However > I'm confused by > > - my colleague Zubin will be working on 9.2.4 next week, hopefully for > release the following week > Sigh, indeed I had meant 9.2.5 here; apologies for the confusion. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ianwookim at gmail.com Thu Oct 13 17:37:11 2022 From: ianwookim at gmail.com (Ian-Woo Kim) Date: Thu, 13 Oct 2022 10:37:11 -0700 Subject: Serious bug in GHC 9.4 on basic math on aarch64 In-Reply-To: References: Message-ID: Thank you all very much for the quick actions. I see that the fix has been made and is under review! - Ian From carter.schonwald at gmail.com Fri Oct 14 16:02:32 2022 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 14 Oct 2022 12:02:32 -0400 Subject: Serious bug in GHC 9.4 on basic math on aarch64 In-Reply-To: References: Message-ID: agreed! This is a nasty one! (the only similar bug i remember in the past is the double/float confusion in 7.6/7.8, but that was a much much harder to trigger bug) On Thu, Oct 13, 2022 at 1:37 PM Ian-Woo Kim wrote: > Thank you all very much for the quick actions. > I see that the fix has been made and is under review! > > - Ian > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gergo.Erdi at sc.com Mon Oct 17 10:33:06 2022 From: Gergo.Erdi at sc.com (Erdi, Gergo) Date: Mon, 17 Oct 2022 10:33:06 +0000 Subject: Missing class op rules when using API Message-ID: PUBLIC Hi, I'm trying to compile the following two modules: ``` {-# LANGUAGE NoImplicitPrelude #-} module MiniMonad where class Functor f where fmap :: (a -> b) -> f a -> f b class (Functor f) => Applicative f where pure :: a -> f a class (Applicative m) => Monad m where return :: a -> m a return = pure (>>=) :: m a -> (a -> m b) -> m b infixl 1 >>= ``` ``` {-# LANGUAGE NoImplicitPrelude #-} module SpecMain where import MiniMonad data Identity a = MkIdentity a instance Functor Identity where fmap f (MkIdentity x) = MkIdentity (f x) instance Applicative Identity where pure x = MkIdentity x instance Monad Identity where run :: Identity a -> a run (MkIdentity x) = x foo :: () foo = run (return ()) ``` If I compile these from the CLI, I see three rules firing: ``` ./_build/stage1/bin/ghc -debug -fforce-recomp -dno-typeable-binds input/SpecMain.hs -iinput -O0 -ddump-rule-rewrites -dsuppress-all ``` ``` [1 of 2] Compiling MiniMonad ( input/MiniMonad.hs, input/MiniMonad.o ) [2 of 2] Compiling SpecMain ( input/SpecMain.hs, input/SpecMain.o ) tc_iface_decl/2 Monad input/SpecMain.hs:14:10: warning: [-Wmissing-methods] * No explicit implementation for '>>=' * In the instance declaration for 'Monad Identity' | 14 | instance Monad Identity where | ^^^^^^^^^^^^^^ Rule fired Rule: Class op $p1Monad Module: (BUILTIN) Before: MiniMonad.$p1Monad TyArg SpecMain.Identity ValArg SpecMain.$fMonadIdentity After: SpecMain.$fApplicativeIdentity Cont: StrictArg MiniMonad.pure ApplyToTy a_avS Stop[RhsCtxt(Recursive)] a_avS -> SpecMain.Identity a_avS Rule fired Rule: Class op pure Module: (BUILTIN) Before: MiniMonad.pure TyArg SpecMain.Identity ValArg SpecMain.$fApplicativeIdentity After: $cpure_aw8 Cont: ApplyToTy a_avS Stop[RhsCtxt(Recursive)] a_avS -> SpecMain.Identity a_avS Rule fired Rule: Class op return Module: (BUILTIN) Before: MiniMonad.return TyArg SpecMain.Identity ValArg SpecMain.$fMonadIdentity After: $creturn_avP Cont: ApplyToTy () ApplyToVal nodup hole () -> SpecMain.Identity () GHC.Tuple.Prim.() Select nodup wild_X1 Stop[RhsCtxt(NonRecursive)] () ``` However, if I try this via the API (see attached `main.hs`), then only `Class op return` fires: ``` Processing module MiniMonad Processing module SpecMain input/SpecMain.hs:14:10: warning: [-Wmissing-methods] * No explicit implementation for '>>=' * In the instance declaration for 'Monad Identity' | 14 | instance Monad Identity where | ^^^^^^^^^^^^^^ Rule fired Rule: Class op return Module: (BUILTIN) Before: MiniMonad.return TyArg SpecMain.Identity ValArg SpecMain.$fMonadIdentity After: $creturn_aqm Cont: ApplyToTy () ApplyToVal nodup hole () -> SpecMain.Identity () GHC.Tuple.Prim.() Select nodup wild_X1 Stop[RhsCtxt(NonRecursive)] () All done. ``` This of course leads to much worse code further downstream (and is catastrophic for my use case where I rely on extensive specialisation). Why is that? What is missing from my `main.hs` that only one of the three method rules is correctly used when compiling the second module? 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.hs Type: application/octet-stream Size: 4037 bytes Desc: main.hs URL: From Gergo.Erdi at sc.com Tue Oct 18 04:50:23 2022 From: Gergo.Erdi at sc.com (Erdi, Gergo) Date: Tue, 18 Oct 2022 04:50:23 +0000 Subject: Missing class op rules when using API In-Reply-To: References: Message-ID: PUBLIC What I've found out is that this was because I was registering the ModDetails as it comes out of tidyProgram. If instead I recreate the ModDetails form the ModIface via initModDetails, the class op rules show up properly and everything works as expected. Is this documented somewhere, that the ModDetails from tidyProgram is not good for all purposes? Should its type be different, then, from an all-purpose ModDetails? From: ghc-devs On Behalf Of Erdi, Gergo via ghc-devs Sent: Monday, October 17, 2022 6:33 PM To: ghc-devs at haskell.org Subject: [External] Missing class op rules when using API Hi, I'm trying to compile the following two modules: ``` {-# LANGUAGE NoImplicitPrelude #-} module MiniMonad where class Functor f where fmap :: (a -> b) -> f a -> f b class (Functor f) => Applicative f where pure :: a -> f a class (Applicative m) => Monad m where return :: a -> m a return = pure (>>=) :: m a -> (a -> m b) -> m b infixl 1 >>= ``` ``` {-# LANGUAGE NoImplicitPrelude #-} module SpecMain where import MiniMonad data Identity a = MkIdentity a instance Functor Identity where fmap f (MkIdentity x) = MkIdentity (f x) instance Applicative Identity where pure x = MkIdentity x instance Monad Identity where run :: Identity a -> a run (MkIdentity x) = x foo :: () foo = run (return ()) ``` If I compile these from the CLI, I see three rules firing: ``` ./_build/stage1/bin/ghc -debug -fforce-recomp -dno-typeable-binds input/SpecMain.hs -iinput -O0 -ddump-rule-rewrites -dsuppress-all ``` ``` [1 of 2] Compiling MiniMonad ( input/MiniMonad.hs, input/MiniMonad.o ) [2 of 2] Compiling SpecMain ( input/SpecMain.hs, input/SpecMain.o ) tc_iface_decl/2 Monad input/SpecMain.hs:14:10: warning: [-Wmissing-methods] * No explicit implementation for '>>=' * In the instance declaration for 'Monad Identity' | 14 | instance Monad Identity where | ^^^^^^^^^^^^^^ Rule fired Rule: Class op $p1Monad Module: (BUILTIN) Before: MiniMonad.$p1Monad TyArg SpecMain.Identity ValArg SpecMain.$fMonadIdentity After: SpecMain.$fApplicativeIdentity Cont: StrictArg MiniMonad.pure ApplyToTy a_avS Stop[RhsCtxt(Recursive)] a_avS -> SpecMain.Identity a_avS Rule fired Rule: Class op pure Module: (BUILTIN) Before: MiniMonad.pure TyArg SpecMain.Identity ValArg SpecMain.$fApplicativeIdentity After: $cpure_aw8 Cont: ApplyToTy a_avS Stop[RhsCtxt(Recursive)] a_avS -> SpecMain.Identity a_avS Rule fired Rule: Class op return Module: (BUILTIN) Before: MiniMonad.return TyArg SpecMain.Identity ValArg SpecMain.$fMonadIdentity After: $creturn_avP Cont: ApplyToTy () ApplyToVal nodup hole () -> SpecMain.Identity () GHC.Tuple.Prim.() Select nodup wild_X1 Stop[RhsCtxt(NonRecursive)] () ``` However, if I try this via the API (see attached `main.hs`), then only `Class op return` fires: ``` Processing module MiniMonad Processing module SpecMain input/SpecMain.hs:14:10: warning: [-Wmissing-methods] * No explicit implementation for '>>=' * In the instance declaration for 'Monad Identity' | 14 | instance Monad Identity where | ^^^^^^^^^^^^^^ Rule fired Rule: Class op return Module: (BUILTIN) Before: MiniMonad.return TyArg SpecMain.Identity ValArg SpecMain.$fMonadIdentity After: $creturn_aqm Cont: ApplyToTy () ApplyToVal nodup hole () -> SpecMain.Identity () GHC.Tuple.Prim.() Select nodup wild_X1 Stop[RhsCtxt(NonRecursive)] () All done. ``` This of course leads to much worse code further downstream (and is catastrophic for my use case where I rely on extensive specialisation). Why is that? What is missing from my `main.hs` that only one of the three method rules is correctly used when compiling the second module? 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Tue Oct 18 11:44:36 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 18 Oct 2022 12:44:36 +0100 Subject: Release Timelines Message-ID: Hi all, Three releases are currently cooking. * 9.2.5 (End of October) - Fixes to performance regressions introduced in 9.2.4. - Fix to interface file determinism - Critical correctness fix for AArch64 code generation * 9.4.3 (End of October) - Critical correctness fix for AArch64 code generation - Fixes to performance regressions introduced in 9.4.2. - Fix to interface file determinism * 9.6.1 (Early 2023) - Branch will be taken in early november. Cheers, Matt From hecate at glitchbra.in Tue Oct 18 11:47:11 2022 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Tue, 18 Oct 2022 13:47:11 +0200 Subject: Release Timelines In-Reply-To: References: Message-ID: Wonderful news, thanks a lot Matthew! Le 18/10/2022 à 13:44, Matthew Pickering a écrit : > Hi all, > > Three releases are currently cooking. > > * 9.2.5 (End of October) > - Fixes to performance regressions introduced in 9.2.4. > - Fix to interface file determinism > - Critical correctness fix for AArch64 code generation > > * 9.4.3 (End of October) > - Critical correctness fix for AArch64 code generation > - Fixes to performance regressions introduced in 9.4.2. > - Fix to interface file determinism > > * 9.6.1 (Early 2023) > - Branch will be taken in early november. > > Cheers, > > Matt > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From matthewtpickering at gmail.com Tue Oct 18 11:48:10 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 18 Oct 2022 12:48:10 +0100 Subject: 9.6.1 branch date - Wednesday 7th Nov Message-ID: Hi all, In order to keep up the 6-month release cadence it is nearly time to take the branch for the 9.6.1 release. The date the branch will be taken is Wednesday 7th Nov. Please reply to this email if there are any in-flight patches which should be included in the 9.6 release. Cheers, Matt From gergo at erdi.hu Tue Oct 18 11:52:24 2022 From: gergo at erdi.hu (=?ISO-8859-2?Q?=C9RDI_Gerg=F5?=) Date: Tue, 18 Oct 2022 19:52:24 +0800 (+08) Subject: Release Timelines In-Reply-To: References: Message-ID: <5d3798aa-a65b-c486-fde-66425d6a738@erdi.hu> On Tue, 18 Oct 2022, Matthew Pickering wrote: > * 9.4.3 (End of October) > - Critical correctness fix for AArch64 code generation > - Fixes to performance regressions introduced in 9.4.2. > - Fix to interface file determinism How about https://gitlab.haskell.org/ghc/ghc/-/issues/22272, a regression from GHC 9.2 with a fix inflight? From hecate at glitchbra.in Tue Oct 18 11:58:43 2022 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Tue, 18 Oct 2022 13:58:43 +0200 Subject: GHC.Pack deprecation process: Step 1 Message-ID: <1c921fa6-397f-d47e-ad1a-3652e6309e6c@glitchbra.in> Hi everyone, As discussed earlier this year¹, the deprecation process for GHC.Pack starts with the 9.6.1 milestone². ¹ https://gitlab.haskell.org/ghc/ghc/-/issues/21461 ² https://gitlab.haskell.org/ghc/ghc/-/issues/21541 Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From alan.zimm at gmail.com Thu Oct 20 20:01:19 2022 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 20 Oct 2022 21:01:19 +0100 Subject: Exact Print Annotations Next Steps Message-ID: I have put down some thoughts about simplifying the exact print annotations, prior to extending them to support printing the `RenamedSource`. See https://gitlab.haskell.org/ghc/ghc/-/issues/22319 Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergo at erdi.hu Fri Oct 28 09:50:19 2022 From: gergo at erdi.hu (=?ISO-8859-2?Q?=C9RDI_Gerg=F5?=) Date: Fri, 28 Oct 2022 17:50:19 +0800 (+08) Subject: Reducing all type family applications as far as possible Message-ID: Hi, Is there a way to have GHC reduce all (reducable) type familiy applications? For example, if I have ``` type family Id x where Id x = x foo :: Bool -> Id Bool foo x = x ``` then I would like the `Id` of `foo` to have type `Bool -> Bool`, and the generated Core should be either `foo = \x -> x` or, if that's asking for too much, at least something like `foo = \x -> x |> (somePossiblyOvercomplicatedCoercion :: Bool ~ Bool)`. Is there already some functionality for this in GHC? If not, how messy would it be to implement it as a separate `CoreProgram` transformation just after desugaring? It'd need to be immediately after desugaring because I would like e.g. the specialiser to already specialise in terms of these reduced types. Thanks, Gergo