[Haskell-cafe] inference with implicitparams seems broken

[Richard Eisenberg]

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> 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
> 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/20220325/6c47a1b7/attachment.html>