<div dir="ltr"><a href="https://github.com/ghc-proposals/ghc-proposals/pull/46">https://github.com/ghc-proposals/ghc-proposals/pull/46</a><div><br></div><div>I tentatively propose that we accept this proposal.</div><div><br></div><div>Briefly, the proposal is to allow a NOUNPACK pragma in a *type signature* to indicate that a value should not be unpacked by the worker-wrapper transformation, e.g.:</div><div><br></div><div><div>insertR :: Ord k => {-# NOUNPACK #-} k -> v -> Map k v -> Map k v</div><div>insertR k v m = go k k v m</div><div>  where</div><div>    go :: Ord k => {-# NOUNPACK #-} k -> k -> v -> Map k v -> Map k v</div><div>    go kp k v m = ...</div></div><div><br></div><div>The idea is that sometimes unpacking a strict argument leads to worse code because the repacking doesn't get simplified away, and it's hard for worker-wrapper to tell that up front. It's quite difficult for the programmer to avoid this problem currently - the one trick we have available is the `lazy` pseudo-function, but that's difficult to use for this purpose because you have to ensure that *all* uses of the argument are made lazy, and there can be collateral damage.  It's the wrong tool to solve this problem, but it's the only tool we have.</div><div><br></div><div>I've had this issue personally, and I've worked around it with `lazy`, but it's an ugly and brittle workaround, and something better is needed.</div><div><br></div><div>If we assume that NOUNPACK can only occur on the left of an arrow (rather like UNPACK/NOUNPACK in a GADT signature), then it's a fairly straightforward extension, and just requires plumbing the information through to the demand analyser / worker-wrapper.</div><div><br></div><div>The dual UNPACK annotation also makes sense, I think, although it's not part of this proposal.  I can imagine it being a future extension.</div><div><br></div><div>Drawbacks I see:</div><div>- It doesn't let you say anything more detailed than just "no", e.g. you can't say "don't unpack the first field of the record"</div><div>- It requires a type signature, which you wouldn't otherwise need.  I suppose you could use PartialTypeSignatures.</div><div>- It doesn't let you say anything about strictness, only unpacking.  If a NOUNPACK argument is inferred by the demand analyser to be strict, callers can use call-by-value.</div><div><br></div><div>Overall I don't see any fatal flaws and there are benefits. It's not a beautiful extension by any means, but I don't think it's expensive or complicated to implement.  I suggest we accept it.  Thoughts?<br></div><div><br></div><div>Cheers</div><div>Simon</div></div>