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

[Richard Eisenberg]

I have volunteered to shepherd Proposal #111: Linear Types. The pull request is here: https://github.com/ghc-proposals/ghc-proposals/pull/111

The authors propose adding linear functions to GHC. The argument to a linear function must be used exactly once in the function body. Motivation for this feature abounds -- essentially, linear types allow for better static checking around resource allocation and deallocation. I refer you to the proposal (and published paper) for more details here. The proposal also contains multiplicity polymorphism, where a higher-order function can be polymorphic in the multiplicity of a supplied function. Datatypes are linear by default, with a long list of (in my opinion, non-obvious) rules around syntax and exceptions to those rules. Constructors have a different multiplicity when used in an expression than they do when used in a pattern, for example. The authors leave type inference as an open question and do not state how the feature would work with either view patterns or pattern synonyms. The proposal comes with a companion document detailing the changes to Core. These changes seem appropriate.

The current proposal has a fair number of open questions. I've written a long comment on the GitHub trail detailing what I was uncertain of. The proposal is not currently near the level of crispness of the proposals we normally accept. For a smaller proposal, I would just send it back to the authors without really giving it to the committee. However, there has been a great deal of effort behind writing this proposal and building an implementation, and so I think it's only fair that we give some thought about the general direction being worked in here.

As to the features themselves: I'm personally far from convinced. Though I see no better way to achieve the authors' goals, the feature they have proposed is full of both sharp and dark corners. If implemented, there would be regular questions cropping up as to why such-and-such is the case or why the design is the way it is. However, this is well motivated and eagerly anticipated. 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 thus recommend: Encouragement to continue the proposal and implementation, with an eye toward acceptance. Furthermore, if/when merged, I would like to advertise that the feature is subject to change, with no backward compatibility guarantee, for several versions. If the feature is implemented and merged, we will learn more about it and then perhaps refine it in the future.

Richard