I'm concerned about the affine-types extension and its impact on ghc and haskell at large

[Bryan Richter]

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, <carter.schonwald at gmail.com>
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
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200219/e448e8c4/attachment.html>