I'm concerned about the affine-types extension and its impact on ghc and haskell at large
b at chreekat.net
Wed Feb 19 08:38:51 UTC 2020
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
> The conditions that would need to be satisfied before a merge are clear and
> include performance requirements:
> 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>
>>> 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
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>> ghc-devs mailing list
>> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs