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

[Joachim Breitner]

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
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180709/af4433f4/attachment.sig>