One downside of this approach is that it requires destructive changes
to work-in-progres branches: I might think the MR is ready, squash the
commit sequence into a single commit, but then more work is ready. Now
it’s hard to revert individual patches, or collaborate with others,
because the git hi
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.
It's hard for me to be helpful here, because I
So does that mean Tidy produces unique `occNameFS`s, and then `Prep`
breaks them?
Tidy does not produce unique OccNames. Rather, it avoids *shadowing*, so
that if you delete all the uniques and print out the program (which is
precisely what happens in an .hi file) you'll still get something sens
Hi,
as Richard rightfully says, this is not an aspect of our workflow that
we should change right now, so consider this thread now a leisurely
coffee machine chat full of hypotheticals, not a concrete call for
action. But I’m happy to elaborate the technical details here.
Am Montag, dem 04.04.202
PUBLIC
OK, I must be doing something wrong then. I am now looking at Tidy (not Prep)
output, and I see Core like this:
showsPrec :: forall a. Show a => Int -> a -> ShowS
[GblId[ClassOp],
Arity=1,
Caf=NoCafRefs,
Str=,
RULES: Built in rule for showsPrec: "Class op showsPrec"]
sho
PUBLIC
Ah, it seems Tidy doesn't traverse the bindings that are created for typeclass
methods. I guess the idea is that I should be able to recreate them from the
typeclass declaration? So how do I know 1. which bindings exactly should be
saved to reconstruct my original full desugared module a
