#686: Amendment to MultilineStrings, recommendation: accept

Dear committee, in https://github.com/ghc-proposals/ghc-proposals/pull/686 Brandon Chinn proposes to slightly modify the recently accepted MultilineStrings proposal: "For the calculation of whitespace prefix removal string gaps (i.e. the / / syntax) should be regarded as non-whitespace." This is technically a breaking change so we should deliberate on it, but I don’t see why anyone would come into this situation in the first place, so I don’t think we should dwell on this. A motivation for the change is that it is easier to implement. I am torn whether it is more or less surprising to users, with maybe a small tendency to less surprising, so I recommend we go with it. The committee could decide to be annoying about this. This is a not strongly motivated change which theoretically changes the semantics of a released extension without warnings or compile errors. However, the extension would surely count as experimental if we were already using the classification we agreed upon. And this tiny change has already been merged as part of a bug fix and I think we should let this pass out of respect to our implementors. Please voice your opinions, I aim to declare this proposal accepted in 7 days. Best Malte

I support the proposal; I have asked some technical questions on the Github
thread.
Simon
On Wed, 19 Mar 2025 at 21:44, Malte Ott
Dear committee,
in
https://github.com/ghc-proposals/ghc-proposals/pull/686
Brandon Chinn proposes to slightly modify the recently accepted MultilineStrings proposal:
"For the calculation of whitespace prefix removal string gaps (i.e. the / / syntax) should be regarded as non-whitespace."
This is technically a breaking change so we should deliberate on it, but I don’t see why anyone would come into this situation in the first place, so I don’t think we should dwell on this.
A motivation for the change is that it is easier to implement. I am torn whether it is more or less surprising to users, with maybe a small tendency to less surprising, so I recommend we go with it.
The committee could decide to be annoying about this. This is a not strongly motivated change which theoretically changes the semantics of a released extension without warnings or compile errors.
However, the extension would surely count as experimental if we were already using the classification we agreed upon. And this tiny change has already been merged as part of a bug fix and I think we should let this pass out of respect to our implementors.
Please voice your opinions, I aim to declare this proposal accepted in 7 days.
Best Malte
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I support this as well!
On Thu, 20 Mar 2025 at 07:09, Simon Peyton Jones via ghc-steering-committee
I support the proposal; I have asked some technical questions on the Github thread.
Simon
On Wed, 19 Mar 2025 at 21:44, Malte Ott
wrote: Dear committee,
in
https://github.com/ghc-proposals/ghc-proposals/pull/686
Brandon Chinn proposes to slightly modify the recently accepted MultilineStrings proposal:
"For the calculation of whitespace prefix removal string gaps (i.e. the / / syntax) should be regarded as non-whitespace."
This is technically a breaking change so we should deliberate on it, but I don’t see why anyone would come into this situation in the first place, so I don’t think we should dwell on this.
A motivation for the change is that it is easier to implement. I am torn whether it is more or less surprising to users, with maybe a small tendency to less surprising, so I recommend we go with it.
The committee could decide to be annoying about this. This is a not strongly motivated change which theoretically changes the semantics of a released extension without warnings or compile errors.
However, the extension would surely count as experimental if we were already using the classification we agreed upon. And this tiny change has already been merged as part of a bug fix and I think we should let this pass out of respect to our implementors.
Please voice your opinions, I aim to declare this proposal accepted in 7 days.
Best Malte
_______________________________________________ ghc-steering-committee mailing list 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
participants (3)
-
Malte Ott
-
Moritz Angermann
-
Simon Peyton Jones