[Haskell-cafe] inference with implicitparams seems broken

[Richard Eisenberg]

Hi Rowan,

Thanks for the detailed answer. For me, there is always a danger in the possibility that I might not realize there is an implicit param in play, but I see your point. To my knowledge, this particular question has not been considered: whether (and how) the MR should apply to implicit parameters. My recommendation, if you want to pursue this, is to post at the ghc-proposals repo. If you're not yet sure exactly what behavior you think would be better, I encourage you to make an Issue first. Issues tend to get good discussion going. Then, once there is some consensus about future directions, you (or someone else) can make a formal proposal to change this behavior.

It's true that the implementation change is easy (I agree with your code), but specification is not so easy sometimes. :)

Richard

> On Mar 28, 2022, at 8:08 AM, rowan goemans <goemansrowan at gmail.com> wrote:
> 
> Hi Richard,
> 
> I understand why the monomorphism restriction is in place. But I feel the reason about potentially repeated computations which are non-obvious aren't really applicable to implicit params. If you use a function with a different implicit param then I don't think anyone would be surprised that it is a different computations. Maybe I'm just not seeing it though. E.g. this is confusing if monomorphism restriction isn't enabled:
> 
> ```
> plus a b = a + b
> 
> res = plus 6 10
> 
> usage1 :: Int
> usage1 = res
> 
> usage2 :: Integer
> usage2 = res
> ```
> 
> as the potentially expensive `plus` computation is ran twice where a user wouldn't expect it to be evaluated twice.
> 
> But something comparable with implicit params isn't confusing I think:
> 
> ```
> plus a = a + ?b 
> 
> res = plus 6
> 
> usage1 :: Int
> usage1 = let ?b = 10 in res
> 
> usage2 :: Integer
> usage2 = let ?b = 10 in res
> ```
> 
> My main point though is whether this was something that was already discussed somewhere with the conclusion being that implicit params should really fall under the monomorphism restriction. Instead of it being an artifact of the current implementation in GHC. Because I would be quite interested in lifting it for implicit params.
> 
> Rowan Goemans
> 
> On 3/25/22 20:17, Richard Eisenberg wrote:
>> Hi Rowan,
>> 
>> The problem is that generalizing a let-binding turns something that looks like a constant into a function. This means that repeated use of the variable will evaluate it separately each time. This can be observed to slow down a program. A key point of the monomorphism restriction is to prevent non-functions from actually being functions. This applies equally well to implicit parameters as to other constraints.
>> 
>> Richard
>> 
>>> On Mar 24, 2022, at 5:37 PM, rowan goemans <goemansrowan at gmail.com <mailto:goemansrowan at gmail.com>> wrote:
>>> 
>>> Hi Richard,
>>> 
>>> Thanks for answering. I have made a tiny change to GHC in a fork that lifts the monomorphization restriction but only for implicit params. See this commit: https://gitlab.haskell.org/rowanG/ghc/-/merge_requests/1/diffs?commit_id=35fcad2d7f556706dd129a57815abe421a559861 <https://gitlab.haskell.org/rowanG/ghc/-/merge_requests/1/diffs?commit_id=35fcad2d7f556706dd129a57815abe421a559861>
>>> Is there some example I could run to see in action why the monomorphisation restriction is required? I looked at the Haskell report and I don't immediately see why the points raised apply to implicit params. I get a feeling that monomorph(Contains only a concrete type like Int or Bool) implicit params would never be a problem and maybe only polymorphic ones are?
>>> 
>>> Rowan Goemans
>>> 
>>> On 3/24/22 20:05, Richard Eisenberg wrote:
>>>> 
>>>> 
>>>>> On Mar 24, 2022, at 9:04 AM, rowan goemans <goemansrowan at gmail.com <mailto:goemansrowan at gmail.com>> wrote:
>>>>> 
>>>>> is this by design/expected though?
>>>> 
>>>> It is by design, yes. With a sufficiently nuanced expectation, I would also say it's expected. (Though, to be fair, if I were not primed to be thinking about the monomorphism restriction, I can't honestly say I would get it right if quizzed.)
>>>> 
>>>>> Would there be interest in fixing this in GHC?
>>>> 
>>>> Figuring out when to generalize a local binding is a hard problem. So, there is definitely interest in finding a better way to do it, but I don't think anyone knows a design that meets the most expectations. Language design is hard! :)
>>>> 
>>>> Richard
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>>> Only members subscribed via the mailman list are allowed to post.
>> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220328/4bdad16b/attachment.html>