<div dir="ltr"><div>Great, thanks for the update!</div><div><br></div><div>I am not at all surprised to hear that this whole thing is being considered intelligently and carefully. :)</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 10:30 AM Boespflug, Mathieu <<a href="mailto:m@tweag.io">m@tweag.io</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"><div dir="ltr">Hi Bryan,<div><br></div><div>the discussion has continued on the original PR for the GHC proposal. See <a href="https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-583795811" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-583795811</a> and following comments.</div><div><br></div><div>The tl;dr is that the concerns raised about performance are far too premature: for their own curiosity someone ran a few benchmarks on the branch of a merge request marked as WIP in the title and which has not yet been performance optimized. See also <a href="https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_longterm_impact_of_the/fgxwk9w/" target="_blank">https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_longterm_impact_of_the/fgxwk9w/</a>. The conditions that would need to be satisfied before a merge are clear and include performance requirements: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-431944078" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-431944078</a>.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 19 Feb 2020 at 09:10, Bryan Richter <<a href="mailto:b@chreekat.net" target="_blank">b@chreekat.net</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"><div dir="ltr"><div dir="auto"><div>Is this true? 6-7% slowdown across the board for all users and all use cases of GHC?</div><div dir="auto"><br></div><div dir="auto">No segment of the community uses all of GHC's features. I, for one, appreciate GHC for its usability and not just its type level wizardry. A great way to improve GHC's usability is to improve compile times. If this does the opposite for everybody, whether they use these new features or not, I am nonplussed.</div><div dir="auto"><br></div><div dir="auto">If Carter is trying to raise concern about this feature, he has been successful. :)<br><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sat, 8 Feb 2020, 2.37 Carter Schonwald, <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@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"><div dir="ltr"><div><a href="https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-583664586" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-583664586</a></div><div><br></div><div><a href="https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_longterm_impact_of_the/" rel="noreferrer" target="_blank">https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_longterm_impact_of_the/</a></div><div><br></div><div>As current maintainer of vector, and a member of the CLC, both of which roles really should be AFFIRMATIONAL stakeholders in this, I only see costs and concerns. <br></div><div><br></div><div>As someone who's spent the past few years doing a LOT of modelling and prototyping around marrying linear logic, formal methods, and functional programming in an applied industrial setting, i should be an Affirmational stakeholder. yet again I am not.<br></div><div><br></div><div>theres very real costs in the complexity and scope of impact that impact EVERY single user and stakeholder of ghc and haskell. And I do not see any concrete population that benefits. <br></div><div><br></div><div><br></div><div>cale even makes a very constructive and articulate point <br></div><div><br></div><div>> I don't know how much my opinion matters at this point, but I'd really like to see the non-toy real-world use cases of this before I can even consider thinking that it would be a good idea to merge to the main compiler. It has such a huge potential impact on so many people in the Haskell community:<br>> <br>>     * Library maintainers who start getting PRs that make "improvements" to linearity while making their libraries harder to maintain because their interface becomes more rigid, and harder to understand because the types are more complicated.<br>> <br>>     * Beginners, or simply ordinary users of the language who have to pay the mental overhead of living with the linear types and polymorphism spreading everywhere as types are adjusted to make terms more usable in places where one is concerned with linearity.<br>> <br>>     * Commercial users of the language who pay for the additional time taken by all their employees waiting for the compiler to run, regardless of whether or not they're using the extension. If Carter's 6-7% slowdown is real even in cases where one doesn't care about the extension, I can imagine wanting to make a fork without the extension. The compiler is already 2 orders of magnitude slower than I'd like. If that weren't the case, maybe 6-7% wouldn't be a huge deal. While ghci is often helpful at shortening the feedback loop, it's not always a viable solution.<br>> <br>> <br>> But really, I just want to know how anyone would put this to practical use in a real setting -- it needs to be _really_ compelling to make up for the social cost. It can't be that hard for Tweag, or someone enthusiastic, to live on a fork until they have a decent case study to show the world, so we can say "okay, that's actually really cool, maybe we actually want that everywhere".<br><br></div></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" rel="noreferrer" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div></div>
</div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
</blockquote></div>