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

newer
is backport planned for 8.8.X of...

older
source-dist from GHC master branch

Carter Schonwald

7 Feb 2020 7 Feb '20

7:37 p.m.

...

I don't know how much my opinion matters at this point, but I'd really

https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-5836645... https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_long... 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 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".

Attachments:

attachment.html (text/html — 3.1 KB)

Show replies by date

Bryan Richter

19 Feb 19 Feb

3:09 a.m.

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, wrote:

...

https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-5836645...

https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_long...

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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Boespflug, Mathieu

3:30 a.m.

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-5837958... 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_long.... 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-4319440... . On Wed, 19 Feb 2020 at 09:10, Bryan Richter 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, wrote:

...
https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-5836645...

https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_long...

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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Bryan Richter

3:38 a.m.

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 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-5837958... 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_long.... 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-4319440... .

On Wed, 19 Feb 2020 at 09:10, Bryan Richter 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, wrote:

...
https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-5836645...

https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_long...

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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1917

Age (days ago)

1928

Last active (days ago)

List overview

Download

3 comments

3 participants

participants (3)

Boespflug, Mathieu
Bryan Richter
Carter Schonwald