[ghc-steering-committee] Proposal #624 on linear let-bindings; recommendation: accept

[Chris Dornan]

+1 from me also

> On 12 Feb 2024, at 22:29, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
>> I'd like to declare this proposal accepted-modulo-tweaks. That is, I'd like to say that we'll accept this proposal, with the understanding that Arnaud and I will work out any remaining design details (as discussed in this thread), including a clear, unambiguous bit of documentation in the user manual and an update proposal. The patch implementing this change (already merged!) has some documentation, but it doesn't accurately reflect the implementation, and so a further patch will be necessary. I can review that further patch, focusing on the documentation piece.
> 
> I support this.
> 
> Simon
> 
> On Mon, 12 Feb 2024 at 15:02, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
>> Summarizing the discussion:
>> 
>> - Only a few have us have joined in. I'll take that as a signal that most don't have an opinion.
>> - There is some design wiggle-room. But there seem to be few strong opinions about how to set the knobs.
>> - Moritz is concerned about backward compatibility, given that there may not be wide knowledge in the community that -XLinearTypes is experimental.
>> 
>> While I agree it is regrettable that GHC itself has no built-in notion of "experimental", I'm not particularly moved by Moritz's concern here (sorry, Moritz!) -- I wager that LinearTypes is known to be pretty new and with sharp edges, and I'm pretty relaxed about changing it. We should prioritize cleaning this up so that we can be clearer in the future about what's experimental and what's not. To be clear, I think backward compatibility / stability is essential for GHC/Haskell, but I also think that until we have these notions baked into GHC (which we should do post-haste), we can use our judgement to determine that this change would not violate most users' assumptions of stability.
>> 
>> I'd like to declare this proposal accepted-modulo-tweaks. That is, I'd like to say that we'll accept this proposal, with the understanding that Arnaud and I will work out any remaining design details (as discussed in this thread), including a clear, unambiguous bit of documentation in the user manual and an update proposal. The patch implementing this change (already merged!) has some documentation, but it doesn't accurately reflect the implementation, and so a further patch will be necessary. I can review that further patch, focusing on the documentation piece.
>> 
>> Any objections to this plan?
>> 
>> Thanks,
>> Richard
>> 
>>> On Jan 25, 2024, at 3:07 AM, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>> 
>>> Arnaud, I agree that _we_ consider LinearTypes experimental. I hope we can get https://github.com/ghc-proposals/ghc-proposals/pull/617 agreed on soon, so that the compiler has
>>> this knowledge as well. I am however not able to fully comprehend the technical details of this proposal right and therefore will defer to others on this!
>>> 
>>> On Thu, 25 Jan 2024 at 16:01, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>>>> Moritz: there's one breakage introduced (but only for users of LinearTypes, which is considered experimental), namely that LinearTypes is proposed to now imply MonoLocalBinds.
>>>> 
>>>> On Thu, 25 Jan 2024 at 07:18, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>>>> I'll have to recuse myself from this, as much of this is currently going above my head. My overall understanding is that
>>>>> this mostly relaxes what we accept, and therefore won't break existing code?
>>>>> 
>>>>> Best,
>>>>>  Moritz
>>>>> 
>>>>> On Thu, 25 Jan 2024 at 00:39, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>>>>>> On Wed, 24 Jan 2024 at 16:39, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>>>>>> Do newtypes make a difference?  E.g      let N x = e in ...
>>>>>>> where N is the data contructor of a newtype?
>>>>>> 
>>>>>> I don't think it has too. So for the moment, I vote to stick to the current proposal and consider this like all lazy non-variable patterns: must be unrestricted.
>>>>>> 
>>>>>> I suspect that there's a possible refinement where we say that a happy pattern is either:
>>>>>> - A variable
>>>>>> - Strict
>>>>>> - A newtype constructor where the inner pattern is happy.
>>>>>> 
>>>>>> (then if pat is an unhappy pattern, `let pat` must be unrestricted).
>>>>>> 
>>>>>> But I don't think I'm quite ready to go there for the time being, and that'll be a backward compatible change if we change our mind.
>>>>>> _______________________________________________
>>>>>> ghc-steering-committee mailing list
>>>>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> 
>>>> 
>>>> --
>>>> Arnaud Spiwack
>>>> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> 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/20240213/e8587a34/attachment-0001.html>