[ghc-steering-committee] Proposal #111: Linear Types
Simon Peyton Jones
simonpj at microsoft.com
Tue Jul 10 07:26:21 UTC 2018
| 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 at cs.brynmawr.edu>
| Sent: 10 July 2018 01:01
| To: Manuel M T Chakravarty <chak at justtesting.org>
| Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-
| committee at haskell.org; Joachim Breitner <mail at 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 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%7C842bbce
| >> | 9f6c2404a
| >> |
| >> | 6ef108d5e5a0d59c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63666
| >> | 740129955
| >> |
| >> | 1567&sdata=28CjA6toUq8RsGk1CxzeFrzI9xUhMsAi4PxJxJzO2zM%3D&r
| >> | eserved=0
| >> _______________________________________________
| >> ghc-steering-committee mailing list
| >> ghc-steering-committee at haskell.org
| >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit
| >> tee
| >
| > _______________________________________________
| > ghc-steering-committee mailing list
| > ghc-steering-committee at haskell.org
| > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ
| > ee
More information about the ghc-steering-committee
mailing list