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 http://www.joachim-breitner.de/