Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings

Simon Peyton Jones simon.peytonjones at gmail.com
Wed Apr 6 08:10:04 UTC 2022 

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.Erdi at 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.peytonjones at gmail.com>
> *Sent:* Wednesday, April 6, 2022 3:37 PM
> *To:* Erdi, Gergo <Gergo.Erdi at sc.com>
> *Cc:* Gergo Érdi <gergo at erdi.hu>; GHC Devs <ghc-devs at haskell.org>;
> clash-language at 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 at 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 at haskell.org> On Behalf Of Gergo Érdi
> Sent: Saturday, April 2, 2022 11:31 AM
> To: Simon Peyton Jones <simon.peytonjones at gmail.com>
> Cc: GHC Devs <ghc-devs at haskell.org>; clash-language at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220406/f43b3d2f/attachment.html>

More information about the ghc-devs mailing list