<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">This sounds interesting, but I don't have time to wade through</div><div class="gmail_default" style="font-family:monospace,monospace">reddit. Aut mailing list aut nihil.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 7 May 2022 at 07:48, Ruben Astudillo <<a href="mailto:ruben.astud@gmail.com">ruben.astud@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I have nothing to say about the topic you propose on here. But to avoid<br>
having a fractured discussion, let's us all agree to answer on that reddit<br>
thread instead of this mail thread. Otherwise some good arguments will be<br>
repeated.<br>
<br>
-- <br>
Rubén. (pgp: 1E88 3AC4 89EB FA22)<br>
<br>
On 06-05-22 15:34, pareto optimal via Haskell-Cafe wrote:<br>
> 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](<a href="https://github.com/search?q=simplified+subsumption+language%3Ahaskell&type=commits" rel="noreferrer" target="_blank">https://github.com/search?q=simplified+subsumption+language%3Ahaskell&type=commits</a>) I see very common patterns in industry Haskell now need an explicit lambda for "reasons" such as:<br>
> <br>
> readFreqSumFile :: (MonadSafe m) => FilePath -> m (FreqSumHeader, Producer FreqSumEntry m ())<br>
> - readFreqSumFile file = readFreqSumProd $ withFile file ReadMode PB.fromHandle<br>
> + readFreqSumFile file = readFreqSumProd $ withFile file ReadMode (\h -> PB.fromHandle h)<br>
> <br>
> and:<br>
> <br>
> - toOrders <- asks _pdfConfToOrder<br>
> + toOrders <- asks (\r -> _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>
> > 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>
> > 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 -> b0 with: forall q. q -> q<br>
> Expected: p -> forall q. q -> q<br>
> Actual: p -> b0 -> 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>
> > me: Ah, that's because of something called simplified subsumption which we'll cover much later.<br>
> > me: For now, just know putting it in an explicit lambda fixes it when you notice a compile error like that.<br>
> > me: Now lets try to move past that and get back to basic file reading and writing<br>
> > 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](<a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst</a>) 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>
> > 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](<a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0274-quick-look-impredicativity.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0274-quick-look-impredicativity.rst</a>).<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](<a href="https://www.microsoft.com/en-us/research/publication/a-quick-look-at-impredicativity/" rel="noreferrer" target="_blank">https://www.microsoft.com/en-us/research/publication/a-quick-look-at-impredicativity/</a>) 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>
> <br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>