Hey Alexis, ive been kicking around some ideas for a specializing lambda former for various uses i've wanted to make tractable, I assume you dont care about polymorphic recursion in the cases you want to specialize? (some of the stuff i want to be able to express requires a sort of type/value binder that needs to be "normalized" before desugaring, but where current meta programming cant express the primops i want ghc to support! so roughly a sortah binder thats like c+ templates, but for types/values that lets me guarantee compositions will specialize before core happens)
On Sat, Mar 14, 2020 at 10:47 PM Alexis King <lexi.lam...@gmail.com> wrote: > On Mar 14, 2020, at 20:03, Sandy Maguire <sa...@sandymaguire.me> wrote: > > What GHC are you testing against? I suspect > https://gitlab.haskell.org/ghc/ghc/merge_requests/668 will fix this. > > > I’ve tested against HEAD. I think the change you link is helpful, but it > doesn’t *quite* get there: the usage gets dumped before specHeader even > gets a chance to look at the call. The relevant bit of code is here: > > > https://gitlab.haskell.org/ghc/ghc/blob/1de3ab4a147eeb0b34b24a3c0e91f174e6e5cb79/compiler/specialise/Specialise.hs#L2274-2302 > > Specifically, this line seals the deal: > > ClassPred cls _ -> not (isIPClass cls) -- Superclasses can't be IPs > > So maybe the right fix is just to change the role of type_determines_value > so that it turns SpecDicts into UnspecArgs, and then with your change > everything would just happily work out. > _______________________________________________ > 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
