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

+1 from me also

On 12 Feb 2024, at 22:29, Simon Peyton Jones 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 mailto:rae@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 mailto:moritz.angermann@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 mailto:arnaud.spiwack@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 mailto:moritz.angermann@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 mailto:arnaud.spiwack@tweag.io> wrote:

...

On Wed, 24 Jan 2024 at 16:39, Simon Peyton Jones mailto:simon.peytonjones@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@haskell.org mailto:ghc-steering-committee@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@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee