<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Rowan,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">It's true that the implementation change is easy (I agree with your code), but specification is not so easy sometimes. :)</div><div class=""><br class=""></div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 28, 2022, at 8:08 AM, rowan goemans <<a href="mailto:goemansrowan@gmail.com" class="">goemansrowan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">Hi Richard,</p><p class="">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:<br class="">
<br class="">
```<br class="">
plus a b = a + b<br class="">
<br class="">
res = plus 6 10<br class="">
<br class="">
usage1 :: Int<br class="">
usage1 = res<br class="">
<br class="">
usage2 :: Integer<br class="">
usage2 = res<br class="">
```</p><p class="">as the potentially expensive `plus` computation is ran twice
where a user wouldn't expect it to be evaluated twice.</p><p class="">But something comparable with implicit params isn't confusing I
think:</p><p class="">```<br class="">
plus a = a + ?b <br class="">
<br class="">
res = plus 6<br class="">
<br class="">
usage1 :: Int<br class="">
usage1 = let ?b = 10 in res<br class="">
<br class="">
usage2 :: Integer<br class="">
usage2 = let ?b = 10 in res<br class="">
```</p><p class="">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.<br class="">
</p>
<div class="moz-cite-prefix">Rowan Goemans</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">On 3/25/22 20:17, Richard Eisenberg
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:010f017fc282e664-0b040474-b0a5-48e2-b855-0c3c38626635-000000@us-east-2.amazonses.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
Hi Rowan,
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Richard<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Mar 24, 2022, at 5:37 PM, rowan goemans
<<a href="mailto:goemansrowan@gmail.com" class="moz-txt-link-freetext" moz-do-not-send="true">goemansrowan@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div class=""><p class="">Hi Richard,</p><p class="">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:
<a class="moz-txt-link-freetext" href="https://gitlab.haskell.org/rowanG/ghc/-/merge_requests/1/diffs?commit_id=35fcad2d7f556706dd129a57815abe421a559861" moz-do-not-send="true">https://gitlab.haskell.org/rowanG/ghc/-/merge_requests/1/diffs?commit_id=35fcad2d7f556706dd129a57815abe421a559861</a></p><p class="">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?</p><p class="">Rowan Goemans<br class="">
</p>
<div class="moz-cite-prefix">On 3/24/22 20:05, Richard
Eisenberg wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:010f017fbd52381d-a86b123e-7216-4cd2-b2ae-3169c8717091-000000@us-east-2.amazonses.com" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Mar 24, 2022, at 9:04 AM, rowan
goemans <<a href="mailto:goemansrowan@gmail.com" class="moz-txt-link-freetext" moz-do-not-send="true">goemansrowan@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span style="caret-color: rgb(0, 0,
0); font-family: Helvetica; font-size: 14px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px;
text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width:
0px; text-decoration: none; float: none;
display: inline !important;" class="">is this
by design/expected though?</span></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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.)</div>
<br class="">
<blockquote type="cite" class="">
<div class=""><span style="caret-color: rgb(0, 0,
0); font-family: Helvetica; font-size: 14px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px;
text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width:
0px; text-decoration: none; float: none;
display: inline !important;" class="">Would
there be interest in fixing this in GHC?</span></div>
</blockquote>
</div>
<br class="">
<div class="">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! :)</div>
<div class=""><br class="">
</div>
<div class="">Richard</div>
</blockquote>
</div>
_______________________________________________<br class="">
Haskell-Cafe mailing list<br class="">
To (un)subscribe, modify options or view archives go to:<br class="">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" class="moz-txt-link-freetext" moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="">
Only members subscribed via the mailman list are allowed
to post.</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
</div>
_______________________________________________<br class="">Haskell-Cafe mailing list<br class="">To (un)subscribe, modify options or view archives go to:<br class=""><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="">Only members subscribed via the mailman list are allowed to post.</div></blockquote></div><br class=""></div></body></html>