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.

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