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

[Simon Peyton Jones]

>
> 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> 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>
> 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>
> 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> 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>
>>> wrote:
>>>
>>>> On Wed, 24 Jan 2024 at 16:39, Simon Peyton Jones <
>>>> 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
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>>
> _______________________________________________
> ghc-steering-committee mailing list
> 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/20240212/2685f59a/attachment-0001.html>