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

[Simon Peyton Jones]

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.
>
> 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/4362d6ca/attachment.html>