- ghc-devs - Haskell.org

how to build Haddock documentation for a single module?
by Norman Ramsey 15 Apr '22

15 Apr '22

I'm fine-tuning the Haddock documentation for just one module that sits in the $GHC/compiler/GHC subtree. Is there a way I can get Hadrian to build the documentation for just that module? Norman

2 2

Markup language/convention for Notes?
by Sebastian Graf 14 Apr '22

14 Apr '22

Hi Devs, When writing Notes, I find myself using markdown-inspired or haddock-inspired features. The reason is that I keep telling myself > In 5 years time, we'll surely have an automated tool that renders Notes referenced under the cursor in a popup in our IDE And I might not be completely wrong about that, after all the strong conventions about Note declaration syntax allow me to do jump-to-definition on Note links in my IDE already (thanks to a shell script written by Zubin!). Still, over the years I kept drifting between markdown and haddock syntax, sometimes used `backticked inline code` or haddock 'ticks' to refer to functions in the compiler (sometimes even 'GHC.Fully.Qualified.ticks') and for code blocks I used all of the following forms: Haddock "code quote" > id :: a -> a > id x = x Markdown triple backticks ```hs id :: a -> a id x = x ``` Indentation by spaces id :: a -> a id x = x And so on. I know that at least Simon was thrown off in the past about my use of "tool-aware markup", perhaps also because I kept switching the targetted tool. I don't like that either. So I wonder Do you think it is worth optimising Notes for post-processing by an external tool?I think it's only reasonable if we decide for a target syntax. Which syntax should it be? Cheers, Sebastian

4 4

Re: Run-time absence info
by David Feuer 13 Apr '22

13 Apr '22

> > Date: Wed, 13 Apr 2022 08:59:06 +0200 > From: Andreas Klebinger <klebinger.andreas(a)gmx.at> > To: ghc-devs(a)haskell.org > Subject: Re: Absence info at run-time > Message-ID: <a577aa9c-6c96-945d-85f6-eb207f88b5b3(a)gmx.at> > Content-Type: text/plain; charset=UTF-8; format=flowed > > W/W should transform such a function into one who takes one less > argument removing any runtime overhead at least for fully applied > functions. > Fully applied functions are definitely not what I'm talking about. I suppose your suggestion is then if we an expression`f x` where bar > takes multiple arguments, but doesn't use the current argument then GHC > should: > > * Inspect f, check if the first argument to f is used > * If we can determine it isn't used instead of creating a PAP capturing > `f` and `x` instead only capture `f` and record this in the PAP closure > somehow. > * Once the PAP is fully applied pass a dummy argument instead of `x` to f. > Yes, that's the idea. The "somehow" is described below. If f is a known call that seems doable, although adding a bitmap to paps > might require us to increase the size of all PAP closures, making this > optimization less useful. > Every PAP has to carry its arity. I just looked it up: typedef struct { StgHeader header; StgHalfWord arity; // number of arguments left to apply, if zero this is an AP closure StgHalfWord n_args; // number of applied arguments StgClosure *fun; // guaranteed to point to a FUN closure StgClosure *payload[]; } StgPAP; On a 64-bit machine, we can combine arity and absence info for functions of up to 31 arguments into half a word. Specifically, set the lowest bit to indicate whether the first argument is used, etc. Then bitwise-or that with 1 `shiftL` arity. Each partial application performed shifts right by the number of arguments applied; if the result is 1, we know it's fully applied. (Any idea why we need the number of arguments that have been applied in the PAP? If that's actually only need for AP, then we might be able to make things a little more compact.) > If `f` is a unknown function there is currently no way to get > absent/used info for it's arguments at runtime. And changing that would > be a major change which seems unlikely to pay off. > I described a mechanism for encoding this concisely above. The same encoding could be used for functions that haven't been partially applied. I don't know where their arities are stashed. In their info tables? > So I think this would be theoretically possible, but it would rarely pay > off. > I'm not sure it's so rare. We end up having to work around this issue in libraries, with varying levels of effort and success. > Also do you have an example where `(const a) b` leads to stupid thunks? > It seems to me const should always be inlined in such a case, avoiding a > PAP allocation. > There won't be a PAP allocation if const inlines. The stupid thunk is a thunk to apply (\ _ -> a) to b. Suppose we define `fmap` for plain arrays (I know; probably not the best example), and let <$ take its default implementation: (<$) a = fmap (const a) If we calculate x <$ arr, that will fill an array with thunks, each of them retaining an element of the original array which will never be used. > Am 12/04/2022 um 23:02 schrieb David Feuer: > > Suppose `f` doesn't use its first argument. When forming the thunk (or > > partial application) `f a`, we don't need to record `a`. What if > > instead of arity, we store a bitmap used/absent arguments, terminated > > by a 1 bit? Could we then get rid of "stupid thunks" like `(const a) b`? > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > ------------------------------ > > Message: 3 > Date: Wed, 13 Apr 2022 08:21:25 +0000 > From: "Sebastian Graf" <sgraf1337(a)gmail.com> > To: "GHC Devs" <ghc-devs(a)haskell.org> > Subject: Markup language/convention for Notes? > Message-ID: <eme97afb2c-f674-4ed3-9d50-52c6482169d0@sebastian-pc> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi Devs, > > When writing Notes, I find myself using markdown-inspired or > haddock-inspired features. The reason is that I keep telling myself > > > In 5 years time, we'll surely have an automated tool that renders > Notes referenced under the cursor in a popup in our IDE > > And I might not be completely wrong about that, after all the strong > conventions about Note declaration syntax allow me to do > jump-to-definition on Note links in my IDE already (thanks to a shell > script written by Zubin!). > Still, over the years I kept drifting between markdown and haddock > syntax, sometimes used `backticked inline code` or haddock 'ticks' to > refer to functions in the compiler (sometimes even > 'GHC.Fully.Qualified.ticks') and for code blocks I used all of the > following forms: > > Haddock "code quote" > > > id :: a -> a > > id x = x > > Markdown triple backticks > > ```hs > id :: a -> a > id x = x > ``` > > Indentation by spaces > > id :: a -> a > id x = x > > And so on. > > I know that at least Simon was thrown off in the past about my use of > "tool-aware markup", perhaps also because I kept switching the targetted > tool. I don't like that either. So I wonder > Do you think it is worth optimising Notes for post-processing by an > external tool?I think it's only reasonable if we decide for a target > syntax. Which syntax should it be? > Cheers, > Sebastian >

1 0

Absence info at run-time
by David Feuer 13 Apr '22

13 Apr '22

Suppose `f` doesn't use its first argument. When forming the thunk (or partial application) `f a`, we don't need to record `a`. What if instead of arity, we store a bitmap used/absent arguments, terminated by a 1 bit? Could we then get rid of "stupid thunks" like `(const a) b`?

2 1

Windows rework merged ; fresh build necessary on Windows
by Ben Gamari 08 Apr '22

08 Apr '22

Hi all, A few minutes ago I merged !7448 and the associated MRs, moving GHC to use the msys2 Clang64 toolchain on Windows. This work improves compilation time, maintainability, and fixes a numerous long-standing bugs affecting Windows and other platforms. However, as a result you may find that in an existing tree `configure` will fail with an error complaining that `clang` can not be found. This is due to the fact that the toolchain tarballs are stale and be fixed with: rm -R _build inplace/mingw win32-tarballs ./boot ./configure --enable-tarballs-autodownload Do let me know if you see any other issues; I'm a bit under the weather at the moment but I'll try to keep an eye on email. Cheers, - Ben

1 0

Warning about glomming
by Gergő Érdi 07 Apr '22

07 Apr '22

Using -DDEBUG, I see a warning about glomming from OccurAnal. Having read the relevant Note, the situation is exactly what's described here: since I'm using cross-module specializations, the specializer will generate rewrite rules that replace external references with local forward references. But the one thing the Note doesn't explicitly state is why this is reported as a warning. It sounds like OccurAnal is well equipped to fix this problem. So is glomming a sign of a problem or is it not? If I see that warning, does that point to a problem in how I use the GHC API, a problem in the code that I'm trying to compile, or neither?

3 2

RE: Re: Shadowing in toIface* output
by Erdi, Gergo 07 Apr '22

07 Apr '22

PUBLIC OK, I must be doing something wrong then. I am now looking at Tidy (not Prep) output, and I see Core like this: showsPrec :: forall a. Show a => Int -> a -> ShowS [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=<S!P(SL,A,A)>, RULES: Built in rule for showsPrec: "Class op showsPrec"] showsPrec = \ (@a_a1G3) (v_B1 :: Show a_a1G3) -> case v_B1 of v_B1 { C:Show v_B2 v_B3 v_B4 -> v_B2 } so if I'm reading this right, these vs are still shadowing. I am using tidyProgram on the output of hscSimplify, and then taking the cg_binds of its result. What else should I do to get tidy (heh) Tidy output? From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Simon Peyton Jones Sent: Monday, April 4, 2022 4:28 PM To: Gergő Érdi <gergo(a)erdi.hu> Cc: GHC Devs <ghc-devs(a)haskell.org> Subject: [External] Re: Shadowing in toIface* output ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Always report suspicious emails using the Report As Phishing button in Outlook to protect the Bank and our clients. So does that mean Tidy produces unique `occNameFS`s, and then `Prep` breaks them? Tidy does not produce unique OccNames. Rather, it avoids shadowing, so that if you delete all the uniques and print out the program (which is precisely what happens in an .hi file) you'll still get something sensible. I'm not sure whether or not Prep maintains this invariant. There is no particular reason it should. It might, but it is not (currently) a goal. Simon On Sat, 2 Apr 2022 at 04:35, Gergő Érdi <gergo(a)erdi.hu<mailto:gergo@erdi.hu>> wrote: So does that mean Tidy produces unique `occNameFS`s, and then `Prep` breaks them? On Fri, Apr 1, 2022 at 10:35 PM Josh Meredith <joshmeredith2008(a)gmail.com<mailto:joshmeredith2008@gmail.com>> wrote: > > Hi, > > I encountered this when we used that for Plutus. I'll have to dig up the details, but IIRC `toIfaceExpr` expects GHC to have already tidied the output, which deals with this issue of overlapping variable names. > > Cheers, > Josh > > On Sat, 2 Apr 2022 at 01:26, ÉRDI Gergő <gergo(a)erdi.hu<mailto:gergo@erdi.hu>> wrote: >> >> Hi, >> >> I'm trying to save (Prep'd) Core bindings right next to the serialized >> `ModIface` (so basically `put_`ing them into the same bytestream, after the >> `ModIface`), and that's exactly what the functions in `GHC.CoreToIface` >> seem to be for, so I expected it to Just Work. However, I noticed that I >> very frequently get problems with shadowing. For example, Core that looks >> like `\v{u1} v{u2} -> v{u1}` would get translated to `\v v -> v`, which is >> disastrous since these locally bound `Var`s are represented as just their >> `getOccFS` (i.e. the `FastString` `"v"`). >> >> But this can't be right: if `toIfaceExpr` &c. would fail this blatently, >> then the unfoldings couldn't be saved & restored, which is something GHC >> itself does as part of normal `.hi` file handling. So clearly I must be >> doing something wrong. >> >> So I guess my question could be, what could be causing `toIfaceExpr` (a >> pure function!) to behave this way for my Cores? But then, if I look at >> the implementation of `toIface*`, I can see that it really doesn't do >> anything smarter than just storing `getOccFS` in the interface (no >> uniques in sight)-- so maybe my *real* question is, what is GHC itself >> doing so that it doesn't have this same problem? >> >> Thanks, >> Gergo >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://clicktime.symantec.com/3BestP7qr2g6Y7xBfCxdDwr6xU?u=http%3A%2F%2Fma…> > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://clicktime.symantec.com/3BestP7qr2g6Y7xBfCxdDwr6xU?u=http%3A%2F%2Fma…> _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://clicktime.symantec.com/3BestP7qr2g6Y7xBfCxdDwr6xU?u=http%3A%2F%2Fma…> 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 3

Release Updates - 9.4.1 and 9.2.3
by Matthew Pickering 07 Apr '22

07 Apr '22

Hi all, We have now forked the 9.4 branch. There are a few outstanding patches which have not yet been finished but which are essential to the release. * (#21019) Windows Toolchain Updates - Ben * (#20405) Partial Register Stall - Ben/Andreas * (!7812) Syntactic Unification - Sam The target date for the first alpha for 9.4.1 is 1st May. We have started preparing the 9.2.3 release in order to fix issues discovered in the 9.2.2 release. I will post separately to the list shortly when the schedule for this release is confirmed. The release manager for this release is Zubin. Cheers, Matt

2 2

Git problem
by Simon Peyton Jones 07 Apr '22

07 Apr '22

Friends I see this bash$ git status On branch wip/romes/ttg-splices-improvements Your branch is up to date with 'origin/wip/romes/ttg-splices-improvements'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) (commit or discard the untracked or modified content in submodules) modified: libraries/Cabal (modified content) modified: libraries/unix (modified content) But I don't want those library changes, whatever they are. They look like Unstaged changes (2) modified libraries/Cabal @@ -1 +1 @@ -Subproject commit d638e33dbc056048b393964286c7fe394b2730d7 +Subproject commit d638e33dbc056048b393964286c7fe394b2730d7-dirty modified libraries/unix @@ -1 +1 @@ -Subproject commit 1f72ccec55c1b61299310b994754782103a617f5 +Subproject commit 1f72ccec55c1b61299310b994754782103a617f5-dirty *But using git submodule update does nothing.* How can I get my submodules in sync with this branch? Thanks Simon

2 2

Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings
by Erdi, Gergo 06 Apr '22

06 Apr '22

PUBLIC Please see this question in my previous email: * Unfortunately, I am unable to reproduce this from the command line using the GHC executable, so before I put in the effort of making a minimal example of using the GHC API to get this result, I would first like to know if this is even an interesting case, or if there is some explanation for why one of these two would have an unfolding when the other doesn't, in certain cases. So I can NOT reproduce it with just a GHC command line, only with my program (that uses GHC as a library). So it will require extra effort to get something you or others can just run, hence my question: is there anything here that is worth pursuing at all? Or who cares, since I'm not using unfoldings anymore (I've switched over to storing IfaceExprs directly), and it works in GHC-the-program? From: Simon Peyton Jones <simon.peytonjones(a)gmail.com> Sent: Wednesday, April 6, 2022 3:37 PM To: Erdi, Gergo <Gergo.Erdi(a)sc.com> Cc: Gergo Érdi <gergo(a)erdi.hu>; GHC Devs <ghc-devs(a)haskell.org>; clash-language(a)googlegroups.com Subject: [External] Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings Hi Gergo If you think GHC has a but, can you open a ticket about this? It's all getting lost in a maze of emails. Can you also give precise repro instructions? In an attempt to reproduce, I have just compiled this module (the code you gave) {-# OPTIONS_GHC -fexpose-all-unfoldings #-} module Foo where nonEmptySubsequences :: [a] -> [[a]] nonEmptySubsequences [] = [] nonEmptySubsequences (x:xs) = [x] : foldr f [] (nonEmptySubsequences xs) where f ys r = ys : (x:ys) : r subsequences :: [a] -> [[a]] subsequences xs = [] : nonEmptySubsequences xs with HEAD, and -O. Unlike you, I see both unfoldings in the interface file. So clearly you and I are doing different things -- but I can't work out what is different without more precision about what you are doing. (It would be harder if it only happens when you use GHC as a library, but I think you are seeing this behaviour in regular GHC.) Thanks Simon On Wed, 6 Apr 2022 at 03:05, Erdi, Gergo <Gergo.Erdi(a)sc.com<mailto:Gergo.Erdi@sc.com>> wrote: PUBLIC Just so this isn't prematurely all lost, I went back and looked for this example. With the following two definitions: subsequences :: [a] -> [[a]] subsequences xs = [] : nonEmptySubsequences xs nonEmptySubsequences :: [a] -> [[a]] nonEmptySubsequences [] = [] nonEmptySubsequences (x:xs) = [x] : foldr f [] (nonEmptySubsequences xs) where f ys r = ys : (x : ys) : r If I save the interface, load it back and look at the unfoldings, I see that `subsequences` has a useful unfolding: subsequences Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 30 10} Whereas `nonEmptySubsequenes` has a trivial one: nonEmptySubsequences OtherCon [] The interface I save is created from the ModDetails returned by tidyProgram. ExposeAllUnfoldings is set. Unfortunately, I am unable to reproduce this from the command line using the GHC executable, so before I put in the effort of making a minimal example of using the GHC API to get this result, I would first like to know if this is even an interesting case, or if there is some explanation for why one of these two would have an unfolding when the other doesn't, in certain cases. -----Original Message----- From: ghc-devs <ghc-devs-bounces(a)haskell.org<mailto:ghc-devs-bounces@haskell.org>> On Behalf Of Gergo Érdi Sent: Saturday, April 2, 2022 11:31 AM To: Simon Peyton Jones <simon.peytonjones(a)gmail.com<mailto:simon.peytonjones@gmail.com>> Cc: GHC Devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>>; clash-language(a)googlegroups.com<mailto:clash-language@googlegroups.com> Subject: [External] Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings I'm using Prep's output (mostly so that it's in ANF) in my full compilation pipeline, so ideally I would save Prep'd Core in my .hi-equivalents so that I don't have to rerun Prep on them every time I use them. I'll get back to you with some concrete examples of `OtherCon []` vs. meaningful unfoldings next week. Merging with my other question about shadowing problems with `toIface*`, in summary it seems that what I really should be doing, is compiling up to Tidy, taking the `CoreBinding`s from there and using `toIfaceBinding` on them to save the definitions. 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<http://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/<http://www.sc.com/rcs/> and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm<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<http://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<https://clicktime.symantec.com/3GBVJVK63nbzRga3gfUDE6Z7VN?u=http%3A%2F%2Fre…>. 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/<http://www.sc.com/en/regulatory-disclosures/dodd-frank/> for important information with respect to derivative products. 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