[ghc-steering-committee] Proposal #111: Linear Types

Tue Jul 10 00:00:45 UTC 2018

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 at 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 at 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 at haskell.org> On
>> |  Behalf Of Joachim Breitner
>> |  Sent: 09 July 2018 14:35
>> |  To: ghc-steering-committee at 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 at joachim-breitner.de
>> |
>> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-
>> |  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C842bbce9f6c2404a
>> |  6ef108d5e5a0d59c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63666740129955
>> |  1567&sdata=28CjA6toUq8RsGk1CxzeFrzI9xUhMsAi4PxJxJzO2zM%3D&reserved=0
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee