Specializing functions with implicit parameters

[Carter Schonwald]

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.lambda at gmail.com> wrote:

> On Mar 14, 2020, at 20:03, Sandy Maguire <sandy at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200315/842e473d/attachment.html>