Hi Bryan, the discussion has continued on the original PR for the GHC proposal. See https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-583795811 and following comments.
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 https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_longterm_impact_of_the/fgxwk9w/. The conditions that would need to be satisfied before a merge are clear and include performance requirements: https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-431944078 . On Wed, 19 Feb 2020 at 09:10, Bryan Richter <[email protected]> wrote: > Is this true? 6-7% slowdown across the board for all users and all use > cases of GHC? > > 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. > > If Carter is trying to raise concern about this feature, he has been > successful. :) > > > On Sat, 8 Feb 2020, 2.37 Carter Schonwald, <[email protected]> > wrote: > >> >> https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-583664586 >> >> >> https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_longterm_impact_of_the/ >> >> 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. >> >> 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. >> >> 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. >> >> >> cale even makes a very constructive and articulate point >> >> > 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: >> > >> > * 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. >> > >> > * 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. >> > >> > * 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. >> > >> > >> > 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". >> >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
