[ghc-steering-committee] #621: Linear constraints, recommendation: accept

[Sebastian Graf]

I vote to return the proposal for revision. I listed my feedback in the
thread
<https://github.com/ghc-proposals/ghc-proposals/pull/621#issuecomment-2601848567>,
but the gist is:

While I am sympathetic to the goal of introducing linearity annotations to
> constraints, simply because it is a logical extension of -XLinearTypes, I
> am afraid I do not feel motivated after having considered the examples in
> the proposal.
>
In fact, I think the examples overpromise on the utility of linear
> constraints and the problems it solves have simpler, more direct solutions.


 Cheers,
Sebastian

Am Di., 14. Jan. 2025 um 23:45 Uhr schrieb Jakob Brünker <
jakob.bruenker at gmail.com>:

> Dear committee,
>
> Arnaud Spiwack and Jack Hughes propose to introduce linear constraints.
>
> These work analogously to linear functions - as can be seen with the new
> syntax, which is %1 =>, reflecting the existing %1 ->. The motivation is
> that these constraints make it possible to design linearly typed APIs that
> are more convenient to use: Without the linear constraints, tokens would
> have to be passed manually into each function in these cases.
>
> The proposal also introduces dupable classes, which can be used multiple
> times even when they appear in a linear context, but cannot be passed to an
> unrestricted function. This is necessary to make some API designs work, see
> the proposal for details.
>
>
> To me, it seems that this proposal or something like it is necessary to
> unlock the full potential of linear types. The proposal lays out why
> monadic API designs don't provide the same benefits, and while there are
> potential future GHC developments that could make using it even more
> convenient (existential types, strict let improvements; see proposal), I
> believe it would already be sufficiently useful with today's GHC to be a
> valuable addition. Thus, I recommend acceptance.
>
> Please read through the proposal and voice your opinions.
>
> Best,
> Jakob
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20250120/d0453fc6/attachment.html>