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

[Boespflug, Mathieu]

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 <b at chreekat.net> 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, <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
>>
> _______________________________________________
> 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/9cb01775/attachment.html>