Specializing functions with implicit parameters

Hi all, I discovered today that GHC never specializes functions with implicit parameters. This is not that surprising—I wouldn’t expect GHC to specialize the implicit parameters themselves—but it’s unfortunate because it means a single implicit parameter somewhere can transitively destroy specialization that would otherwise be very helpful. Is there any obstacle to specializing these functions’ other dictionaries and leaving the implicit parameters alone? That is, if I have a function foo :: (?foo :: Bool, Show a) => a -> String could GHC specialize `foo @Int` to foo :: (?foo :: Bool) => Int -> String treating the implicit parameter little differently from an ordinary function argument? As far as I can tell, there isn’t any real obstacle to doing this, so unless I’m missing something, I might give it a try myself. I just wanted to make sure I wasn’t missing anything before diving in. Thanks, Alexis

What GHC are you testing against? I suspect
https://gitlab.haskell.org/ghc/ghc/merge_requests/668 will fix this.
On Sat, Mar 14, 2020 at 4:20 PM Alexis King
Hi all,
I discovered today that GHC never specializes functions with implicit parameters. This is not that surprising—I wouldn’t expect GHC to specialize the implicit parameters themselves—but it’s unfortunate because it means a single implicit parameter somewhere can transitively destroy specialization that would otherwise be very helpful.
Is there any obstacle to specializing these functions’ other dictionaries and leaving the implicit parameters alone? That is, if I have a function
foo :: (?foo :: Bool, Show a) => a -> String
could GHC specialize `foo @Int` to
foo :: (?foo :: Bool) => Int -> String
treating the implicit parameter little differently from an ordinary function argument?
As far as I can tell, there isn’t any real obstacle to doing this, so unless I’m missing something, I might give it a try myself. I just wanted to make sure I wasn’t missing anything before diving in.
Thanks, Alexis _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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 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... 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.

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

Spot on Alexis. Should not be hard to fix this.
I think the best thing would be in mkCallUDs
* not to use SpecDict for implicit parameters; instead use UnspecArg
* don’t require length theta = length dicts. Need to think about what else instead. Isn’t it implied by the arity test?
Make a ticket! Happy to help if you or Sandy need anything from me.
Simon
From: ghc-devs
participants (4)
-
Alexis King
-
Carter Schonwald
-
Sandy Maguire
-
Simon Peyton Jones