| I want to second Manuel's arguments here -- I don't think we can suggest | that someone forks the compiler. +1. It's possible in theory, as I said, but in practice it'd kill the proposal. It's also worth bearing in mind that the proposers have made a very substantial investment in getting it this far, precisely because it is a "big" proposal. Simon | -----Original Message----- | From: Richard Eisenberg <rae@cs.brynmawr.edu> | Sent: 10 July 2018 01:01 | To: Manuel M T Chakravarty <chak@justtesting.org> | Cc: Simon Peyton Jones <simonpj@microsoft.com>; ghc-steering- | committee@haskell.org; Joachim Breitner <mail@joachim-breitner.de> | Subject: Re: [ghc-steering-committee] Proposal #111: Linear Types | | I want to second Manuel's arguments here -- I don't think we can suggest | that someone forks the compiler. In effect, this is already true during | development. Speaking as the developer of TypeInType (which I think is an | apt comparison in many respects to LinearTypes), operating on a fork cost me | a lot of time indeed. There's no other way to do it during development, but | it's not sustainable for very long. | | Simon M, you've made good points about the motivations. Perhaps could you | summarize your thoughts on the GitHub trail so we can get a response from | the proposal authors? | | Thanks, | Richard | | > On Jul 9, 2018, at 11:03 AM, Manuel M T Chakravarty <chak@justtesting.org> | wrote: | > | > I don’t think relegating an accepted proposal to a fork is a reasonable | alternative. Why go through the, for a large proposal, rather painful | proposal process just so that you can do what you can also do without that | blessing? | > | > In fact, if we are going to take that stance, I think, we will seriously | discourage contributions to GHC that involve more substantial language | changes. I think that would be a very bad development as it makes GHC a much | less attractive vehicle for that sort of research. | > | > By their nature, proposals that fall into that category (that they have a | serious impact on GHC) are also the ones that are the most painful to | maintain as a fork. Serious impact means a large overlap with central | elements of the compiler, which are constantly changing and hence require | constant attention (rebasing, tracking bug fixes[1], etc) from the team | maintaining the fork. | > | > Specifically concerning the linear types proposal, I can assure you that | maintaining the fork has very significant costs (time which maybe would have | been better spent on improving the contribution rather than just chasing | after the main compiler). At some point, these costs need to pay their dues | and lead to inclusion into the compiler; otherwise, the fork will die like | many in GHC’s past have. | > | > I also don’t think, we can compare the situation to LH. Firstly, an | extension needs to meet certain properties so that it can go into what is | effectively a post-processor. Secondly, the structure of LH is currently | rather incompatible with that of GHC (specifically generating type errors in | a Core pass). So, having a separate implementation was probably the easier | way to get started anyway. | > | > As for GHCJS, they do pay a high price and constantly lag behind the main | compiler. Moreover, they do ”only” change the backend. The maintenance | burden for an extension that affects everything starting from the frontend | is much higher. | > | > In summary, I think, we need to bite the bullet. If the *potential* gain | of an extension is sufficiently high and it passes the proposal process, I | think, we need to allow it into the main compiler. Otherwise, GHC’s | potential as a research vehicle will be seriously limited. | > | > Cheers, | > Manuel | > | > [1] Including running into bugs that have already been fixed in the main | compiler and wasting precious development time on them. | > | >> Am 09.07.2018 um 15:43 schrieb Simon Peyton Jones via ghc-steering- | committee <ghc-steering-committee@haskell.org>: | >> | >> | How feasible would it to have a “lghc” fork that early adaptors can | use ? | >> | >> Obviously not impossible. It'd imply a constant rebase burden. That's | different to GHCJS and LH, which are much more modularly separable. | >> | >> The key thing is the signal we send to the authors. It could mean "go on | a fork so we don't need to worry about you any more" (After all, *anyone* | can create a fork.... it does not need the committee's blessing.) Or it | could mean "we really like this and want to get more experience of it". | It'd be good to have a tangible way to express that difference. | >> | >> Simon | >> | >> | -----Original Message----- | >> | From: ghc-steering-committee | >> | <ghc-steering-committee-bounces@haskell.org> On Behalf Of Joachim | >> | Breitner | >> | Sent: 09 July 2018 14:35 | >> | To: ghc-steering-committee@haskell.org | >> | Subject: Re: [ghc-steering-committee] Proposal #111: Linear Types | >> | | >> | Hi, | >> | | >> | Am Sonntag, den 08.07.2018, 23:41 -0400 schrieb Richard Eisenberg: | >> | > And I don't think we'll be able to conjure up a better design | >> | without > gaining experience with the proposed design, however flawed. | >> | | >> | I am wondering if we need in general a better way of allowing | >> | high- risk/high-impact implementations to be tested in practice | >> | without needing to merge them into the main compiler directly first. | >> | | >> | In a way Liquid Haskell is an example here. If Refinement Types | >> | were proposed in a GHC proposal a few years ago we’d be in a | >> | similarly hard spot judging its merit. But the LH people chose a | >> | different path: They (more or | >> | less) forked GHC, users who want to play around with it have to | >> | install a separate program, but development can happen | >> | independently, more rapidly and without the commitments to | >> | stability that we expect from GHC. The downside is, of course, | >> | less adoption, no integration into existing libraries and maintenance | overhead. | >> | | >> | GHCJS is another example of that model. | >> | | >> | How feasible would it to have a “lghc” fork that early adaptors can | use ? | >> | I’d allow us to learn more about this feature, in particular its | >> | user experience, user needs and adoption? If indeed existing code | >> | will continue work as is, then a user of “lghc” still has all of | >> | Hackage at their fingertips, so it seems somewhat realistic that a | >> | user who is excited about linear types will actually use “lghc”. | >> | | >> | Cheers, | >> | Joachim | >> | | >> | -- | >> | Joachim Breitner | >> | mail@joachim-breitner.de | >> | | >> | | >> | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww | >> | .joachim- | >> | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C842bbce | >> | 9f6c2404a | >> | | >> | 6ef108d5e5a0d59c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63666 | >> | 740129955 | >> | | >> | 1567&sdata=28CjA6toUq8RsGk1CxzeFrzI9xUhMsAi4PxJxJzO2zM%3D&r | >> | eserved=0 | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit | >> tee | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ | > ee