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.
>
> 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
