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

Simon Peyton Jones simonpj at microsoft.com
Mon Jul 9 13:43:38 UTC 2018


|  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


More information about the ghc-steering-committee mailing list