So does that mean Tidy produces unique `occNameFS`s, and then `Prep`
breaks them?
On Fri, Apr 1, 2022 at 10:35 PM Josh Meredith
wrote:
>
> Hi,
>
> I encountered this when we used that for Plutus. I'll have to dig up the
> details, but IIRC `toIfaceExpr` expects GHC to have already tidied the
>
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 unfoldi
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 [] unfo
I have opened #21333 to track this poor documentation of tidyProgram.
Zubin may be right about implicit bindings (as I remark in the ticket) but
if so we should fix that so that the no-shadowing invariant does hold. I
don't want clients to have to work around this, as Zubin implies HLS is
doing.
I suspect these are implicit bindings that you will need to filter out
and regenerate from the tycons.
You might find this HLS PR instructive as it implements something quite similar
to what you seem to want:
https://github.com/haskell/haskell-language-server/pull/2813
It is also relevant to qu
Hi,
I encountered this when we used that for Plutus. I'll have to dig up the
details, but IIRC `toIfaceExpr` expects GHC to have already tidied the
output, which deals with this issue of overlapping variable names.
Cheers,
Josh
On Sat, 2 Apr 2022 at 01:26, ÉRDI Gergő wrote:
> Hi,
>
> I'm tryin
Hi,
I'm trying to save (Prep'd) Core bindings right next to the serialized
`ModIface` (so basically `put_`ing them into the same bytestream, after the
`ModIface`), and that's exactly what the functions in `GHC.CoreToIface`
seem to be for, so I expected it to Just Work. However, I noticed that
On Fri, 1 Apr 2022, Sylvain Henry wrote:
The unfolding is present if you add `-fno-omit-interface-pragmas` and dump
with `-ddump-simpl`. CorePrep drops unfoldings, see Note [Drop unfoldings and
rules] in GHC.CoreToStg.Prep.
Thanks, I forgot to mention that I am already using
`NoOmitInterface
The unfolding is present if you add `-fno-omit-interface-pragmas` and
dump with `-ddump-simpl`. CorePrep drops unfoldings, see Note [Drop
unfoldings and rules] in GHC.CoreToStg.Prep.
The logic for unfolding exposition by Tidy is now in:
https://gitlab.haskell.org/ghc/ghc/-/blob/a952dd80d40bf6b
This doesn't quite match my experience. For example, the following
toplevel definition gets an `OtherCon []` unfolding:
nonEmptySubsequences :: [a] -> [[a]]
nonEmptySubsequences [] = []
nonEmptySubsequences (x:xs) = [x] : foldr f [] (nonEmptySubsequences xs)
where
f ys r = ys : (x:ys) : r
So if I understand correctly, OtherCon is only created here:
https://gitlab.haskell.org/ghc/ghc/-/blob/a952dd80d40bf6b67194a44ff71d7bf75957d29e/compiler/GHC/Core/Opt/Simplify.hs#L3071-3077
simplAlt env _ imposs_deflt_cons case_bndr' cont' (Alt DEFAULT bndrs rhs)
= assert (null bndrs) $
do {
Hi all,
Currently the windows CI issue is experiencing high amounts of
instability so if your patch fails for this reason then don't worry.
We are attempting to fix it.
Cheers,
Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org
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 lar
13 matches
Mail list logo
