<div style='font-family:arial; font-size:13px;'>I originally posted on Reddit and the thread contains much debate and discussion.<br><br>I'm concerned the views of the mailing list and likely ghc devs might not be as represented there or discourse, so i'm also copying it here.<br><br>Copy-paste of post:<br><br>Warning: Long post<br><br>tl;dr<br><br>- simplified subsumption seems to make common code I write in industry clunky for no good reason in lots of places<br><br>- Are others concerned with motivating what seem like "pointless lambdas" to new hires or students for simple tasks?<br><br>- Are there more real world advantages that make these frequent annoyances worth it?<br><br>- How is quicklook impredicativity useful in industry?<br><br>The biggest advantage seems to be that laziness is more predictable.<br><br>However looking at [commits fixing simplified subsumption errors on github](https://github.com/search?q=simplified+subsumption+language%3Ahaskell&amp;type=commits) I see very common patterns in industry Haskell now need an explicit lambda for "reasons" such as:<br><br><br>      readFreqSumFile :: (MonadSafe m) =&gt; FilePath -&gt; m (FreqSumHeader, Producer FreqSumEntry m ())<br>    - readFreqSumFile file = readFreqSumProd $ withFile file ReadMode PB.fromHandle<br>    + readFreqSumFile file = readFreqSumProd $ withFile file ReadMode (\h -&gt; PB.fromHandle h)<br><br>and:<br><br>    - toOrders &lt;- asks _pdfConfToOrder<br>    + toOrders &lt;- asks (\r -&gt; _pdfConfToOrder r)<br><br>And this typical use of id is no longer valid:<br><br>    instance MonadOrvilleControl IO where<br>    -    liftWithConnection = id<br>    -    liftFinally = id<br>    +   liftWithConnection ioWithConn = ioWithConn<br>    +   liftFinally ioFinally = ioFinally<br><br>On my $work codebase that means hundreds of changes that make our code worse with seemingly no benefit.<br><br>This case is addressed in the proposal, but seems to handwave this as:<br><br>&gt; The benefit, in terms of programming convenience, is small.<br><br>From my perspective while updating my codebase, it certainly doesn't feel that way.<br><br>From the persective of onboarding new Haskell hires, it doesn't feel simpler. I envision a future teaching session like:<br><br>&gt; student: This code looks correct but I get an error that means nothing to me of<br><br>     error:<br>         • Couldn't match type: b0 -&gt; b0 with: forall q. q -&gt; q<br>              Expected: p -&gt; forall q. q -&gt; q<br>              Actual: p -&gt; b0 -&gt; b0<br>         • In the first argument of ‘g’, namely ‘f’ In the expression: g f In an equation for ‘h’: h = g f | | h = g f | ^<br><br>&gt; me: Ah, that's because of something called simplified subsumption which we'll cover much later.<br>&gt; me: For now, just know putting it in an explicit lambda fixes it when you notice a compile error like that.<br>&gt; me: Now lets try to move past that and get back to basic file reading and writing<br>&gt; student: oookkkay? (feeling unsure, disillusioned about Haskell requiring pointless ceremony and being overly complex for no seeming benefit)<br><br>Being a fan of and proponent of Haskell I think: If this complication is being added, surely something is made possible in return that gives more value.<br><br>This led me to [the proposal](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst) and I found with simplified subsumption:<br><br>- Laziness characteristics and semantics of programs will be changed less, which I infer will lead to more predictable performance<br>- I assume that simplifying a compiler step like this will speed up compile times and reduce space usage<br>- Quick look impredicativity seems to be the real driving reason behind simplified subsumption and somehow makes dealing with very polymorphic code easier<br><br>At this point my thought is:<br><br>&gt; Making highly polymorphic code simpler to write that isn't as typical in industry Haskell code in ways I can't determine without great effort was valued over "small incoveniences" that I'll run into daily<br><br>But, still wanting to give the benefit of the doubt I dive face first into [The proposal for Quicklook impredicativity](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0274-quick-look-impredicativity.rst).<br><br>Reading the whole thing, I still cannot ground this concept in real world terms that may effect me or that I could take advantage of.<br><br>So, I go to the paper [A quick look at impredicativity](https://www.microsoft.com/en-us/research/publication/a-quick-look-at-impredicativity/) and start reading many things I don't fully understand.<br><br>Running out of energy, I start skimming and finally find some examples in section 10 APPLICATIONS.<br><br>I see an example with gZipWithM that I still don't understand. Further down I see reference to pieces of code updated in Streamly that take advantage of quick look polymorphism and wonder why the real world example wasn't included and explained.<br><br>So, i'm left frustrated with "simplified" subsumption and posting here for help answering:<br><br>- Are others in the same boat?<br>- Are there advantages i'm not seeing?<br>- Can we use my reflection to improve industry/academic communication?<br><br>And finally, any revant commentary surrounding this I may be oblivious to.<br><br>Thanks!<br><br></div>