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. On Sat, Apr 2, 2022 at 12:53 AM Simon Peyton Jones <simon.peytonjo...@gmail.com> wrote: > > I don't think any top-level Ids should have OtherCon [] unfoldings? If they > do, can you give a repro case? OtherCon [] unfoldings usually mean "I know > this variable is evaluated, but I don't know what its value is. E.g > data T = MkT !a !a > f (MkT x y) = ... > > here x and y have OtherCon [] unfoldings. They are definitely not bottom! > > You may want stronger invariants on the output of CorePrep than we have > hitherto sought. Can you explain what they are? And why you want the output > of CorePrep not CoreTidy? > > Thanks > > Simon > > On Fri, 1 Apr 2022 at 09:13, ÉRDI Gergő <ge...@erdi.hu> wrote: >> >> Hi, >> >> I'm CC-ing the Clash mailing list because I believe they should have >> encountered the same problem (and perhaps have found a solution to it >> already!). >> >> I'm trying to use `.hi` files compiled with `ExposeAllUnfoldings` set to >> reconstruct full Core bindings for further processing. By and large, this >> works, but I get tripped up on identifiers whose unfolding is only given >> as `OtherCon []`. It is unclear to me what is causing this -- some of them >> are recursive bindings while others are not. >> >> The problem, of course, is that if all I know about an identifier is that >> it is `OtherCon []`, that doesn't allow me to restore its definition. So >> is there a way to tell GHC to put "full" unfoldings everywhere in >> `ExposeAllUnfoldings` mode? >> >> Thanks, >> Gergo >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
