[Haskell-cafe] inference with implicitparams seems broken

[rowan goemans]

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> 
>> 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
>>
>> 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> 
>>>> 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/20220328/444de0c4/attachment.html>