OK. As I said earlier, the 'OtherCon []' unfoldings are unexpected to me. But if
- We can't reproduce it without a lot of effort - It's not important to you any more then let's just let it lie. Simon On Wed, 6 Apr 2022 at 08:51, Erdi, Gergo <gergo.e...@sc.com> wrote: > 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.peytonjo...@gmail.com> > *Sent:* Wednesday, April 6, 2022 3:37 PM > *To:* Erdi, Gergo <gergo.e...@sc.com> > *Cc:* Gergo Érdi <ge...@erdi.hu>; GHC Devs <ghc-devs@haskell.org>; > clash-langu...@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.e...@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-boun...@haskell.org> On Behalf Of Gergo Érdi > Sent: Saturday, April 2, 2022 11:31 AM > To: Simon Peyton Jones <simon.peytonjo...@gmail.com> > Cc: GHC Devs <ghc-devs@haskell.org>; clash-langu...@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 > > 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 > <https://clicktime.symantec.com/3GBVJVK63nbzRga3gfUDE6Z7VN?u=http%3A%2F%2Fresearch.sc.com%2Fresearch%2Fapi%2Fapplication%2Fstatic%2Fterms-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. > > > 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. >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs