<div dir="ltr"><div>I vote to return the proposal for revision. <a href="https://github.com/ghc-proposals/ghc-proposals/pull/621#issuecomment-2601848567">I listed my feedback in the thread</a>, but the gist is:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
While I am sympathetic to the goal of introducing linearity annotations 
to constraints, simply because it is a logical extension of <code class="gmail-notranslate">-XLinearTypes</code>,
 I am afraid I do not feel motivated after having considered the 
examples in the proposal. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In fact, I think the examples overpromise on 
the utility of linear constraints and the problems it solves have 
simpler, more direct solutions.

</blockquote><div><br></div><div> Cheers,</div><div>Sebastian<br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Am Di., 14. Jan. 2025 um 23:45 Uhr schrieb Jakob Brünker <<a href="mailto:jakob.bruenker@gmail.com">jakob.bruenker@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Dear committee,<br><br></div><div>Arnaud Spiwack and Jack Hughes propose to introduce linear constraints.</div><div><br></div><div>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.</div><div><br></div><div>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.<br><br></div><div><br></div><div>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.<br><br></div><div>Please read through the proposal and voice your opinions.</div><div><br></div><div>Best,</div><div>Jakob</div></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>