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

[Bryan Richter]

Great, thanks for the update!

I am not at all surprised to hear that this whole thing is being considered
intelligently and carefully. :)


On Wed, Feb 19, 2020 at 10:30 AM Boespflug, Mathieu <m at tweag.io> wrote:

> 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/f753c51d/attachment.html>