Re: Specializing functions with implicit parameters

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 wrote:

On Mar 14, 2020, at 20:03, Sandy Maguire 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/1de3ab4a147eeb0b34b24a3c0e91f174e6e5...

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