<div dir="ltr">I support this as well!</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 20 Mar 2025 at 07:09, Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a>> wrote:<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 class="gmail_default" style="font-family:tahoma,sans-serif">I support the proposal; I have asked some technical questions on the Github thread.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 19 Mar 2025 at 21:44, Malte Ott <<a href="mailto:malte.ott@maralorn.de" target="_blank">malte.ott@maralorn.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear committee,<br>
<br>
in<br>
<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/686" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/686</a><br>
<br>
Brandon Chinn proposes to slightly modify the recently accepted MultilineStrings<br>
proposal:<br>
<br>
"For the calculation of whitespace prefix removal string gaps (i.e. the /   /<br>
syntax) should be regarded as non-whitespace."<br>
<br>
This is technically a breaking change so we should deliberate on it, but I don’t see<br>
why anyone would come into this situation in the first place, so I don’t think<br>
we should dwell on this.<br>
<br>
A motivation for the change is that it is easier to implement. I am torn whether<br>
it is more or less surprising to users, with maybe a small tendency to less<br>
surprising, so I recommend we go with it.<br>
<br>
The committee could decide to be annoying about this. This is a not strongly<br>
motivated change which theoretically changes the semantics of a released<br>
extension without warnings or compile errors. <br>
<br>
However, the extension would surely count as experimental if we were already using the<br>
classification we agreed upon. And this tiny change has already been merged<br>
as part of a bug fix and I think we should let this pass out of respect to our<br>
implementors.<br>
<br>
Please voice your opinions, I aim to declare this proposal accepted in 7 days.<br>
<br>
Best<br>
Malte<br>
<br>
_______________________________________________<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>
_______________________________________________<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>