But why wait? There is no implementation-related uncertainty here. It's just a question of writing a precise spec. It's not even difficult to do! Sometimes making the spec precise throws up unexpected wrinkles. I'm not against postponing things where the implementation may influence details of the spec. But that's not the case here, I think. Simon On Wed, 3 Jan 2024 at 12:43, Richard Eisenberg wrote:

I agree that some aspects of this proposal are not as precise as I'd like. But actually I think we should accept before these last few details are worked out. Unless I'm mistaken, there's not a worry that the specific choices will change our minds, and the details will have to be resolved in the course of implementation. Ideally, the proposer will come back and update the proposal. However, the proposal is not the long-lasting record of the specification; the user manual is. (By contrast, the proposal is the long-lasting record of the motivation / discussion / alternatives.) So I would insist in the code-review process that the manual is fully precise, and perhaps to insist that the proposal has a note saying it will be made precise in the course of implementation -- but I don't think we need this to happen before acceptance. Sometimes the details are easier to work out during implementation and can be informed by the tiny bit of experience gained writing tests, etc.

Richard

PS: The viewpoint here -- to work out final details late -- is informed by the common practice at Jane Street. We sketch out a broad idea with a bunch of examples, but we write down the final specification only after implementing. This is so much easier, because it makes the specification process iterative with implementation.

On Jan 3, 2024, at 7:17 AM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

I'm content to accept, but only when the specification is made precise.

Simon

On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg wrote:

...

After some conversation on the ticket, I'd like to vote for acceptance here.

Richard

...

On Jan 1, 2024, at 9:46 AM, Richard Eisenberg wrote:

Yes that's true of course, but if we had a design that could cover raw strings as well, then we have one fewer quoting construct. I guess the real question is: do we need the ability to toggle between multiline and raw separately? That is, right now we have cooked single-line strings. This proposal is for cooked multiline strings, leaving raw strings for a separate proposal. But maybe we only need cooked single-line strings and raw multiline ones? That would be simpler.

I think wisdom from other languages would be helpful here. I will post on the ticket.

Richard

...

On Dec 31, 2023, at 12:04 PM, Eric Seidel wrote:

...

On Dec 29, 2023, at 07:19, Richard Eisenberg wrote:

On the other hand, I'm a little worried that this doesn't have support for raw strings. That is, even with this, there will still be some users who reach for quasiquotes for multi-line strings, if those strings contain backslashes.

I had a similar thought at first, but I think raw strings can be added independently of this proposal. So long as we are not closing the door to a future addition I think it is fine to take incremental steps.

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

If there is a consensus to accept, we can say "Accept provided you make the spec precise, and that process does not throw up any unexpected surprises". I agree that requiring a fully-precise spec for a subsequently-rejected proposal is dispiriting. But I worry that if we kick the can down the road - there is no mechanism to ensure subsequent precision - code reviewers have no spec wrt which to review the code so maybe it never gets done at all. Simon On Wed, 3 Jan 2024 at 12:52, Richard Eisenberg wrote:

On Jan 3, 2024, at 7:47 AM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

But why wait?

To reduce the burden of the proposal process. From the point of view of the proposer, putting yet more time into an as-yet-unaccepted proposal is a hoop to jump through, with uncertain outcome.

As we can observe, writing precise specifications is generally not easy. (If it were easy, then we should expect most proposals to come with one. But almost all proposals are insufficiently precise upon inspection.) I'm just trying to nudge us toward making the process easier (for us, too!).

Richard

There is no implementation-related uncertainty here. It's just a question of writing a precise spec. It's not even difficult to do!

Sometimes making the spec precise throws up unexpected wrinkles.

I'm not against postponing things where the implementation may influence details of the spec. But that's not the case here, I think.

Simon

On Wed, 3 Jan 2024 at 12:43, Richard Eisenberg wrote:

...

I agree that some aspects of this proposal are not as precise as I'd like. But actually I think we should accept before these last few details are worked out. Unless I'm mistaken, there's not a worry that the specific choices will change our minds, and the details will have to be resolved in the course of implementation. Ideally, the proposer will come back and update the proposal. However, the proposal is not the long-lasting record of the specification; the user manual is. (By contrast, the proposal is the long-lasting record of the motivation / discussion / alternatives.) So I would insist in the code-review process that the manual is fully precise, and perhaps to insist that the proposal has a note saying it will be made precise in the course of implementation -- but I don't think we need this to happen before acceptance. Sometimes the details are easier to work out during implementation and can be informed by the tiny bit of experience gained writing tests, etc.

Richard

PS: The viewpoint here -- to work out final details late -- is informed by the common practice at Jane Street. We sketch out a broad idea with a bunch of examples, but we write down the final specification only after implementing. This is so much easier, because it makes the specification process iterative with implementation.

On Jan 3, 2024, at 7:17 AM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

I'm content to accept, but only when the specification is made precise.

Simon

On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg wrote:

...

After some conversation on the ticket, I'd like to vote for acceptance here.

Richard

...

On Jan 1, 2024, at 9:46 AM, Richard Eisenberg wrote:

Yes that's true of course, but if we had a design that could cover raw strings as well, then we have one fewer quoting construct. I guess the real question is: do we need the ability to toggle between multiline and raw separately? That is, right now we have cooked single-line strings. This proposal is for cooked multiline strings, leaving raw strings for a separate proposal. But maybe we only need cooked single-line strings and raw multiline ones? That would be simpler.

I think wisdom from other languages would be helpful here. I will post on the ticket.

Richard

...

On Dec 31, 2023, at 12:04 PM, Eric Seidel wrote:

...

On Dec 29, 2023, at 07:19, Richard Eisenberg wrote:

On the other hand, I'm a little worried that this doesn't have support for raw strings. That is, even with this, there will still be some users who reach for quasiquotes for multi-line strings, if those strings contain backslashes.

I had a similar thought at first, but I think raw strings can be added independently of this proposal. So long as we are not closing the door to a future addition I think it is fine to take incremental steps.

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

But there is! Code review, for the user manual entry.

I just think that often will not happen. I am also genuinely unclear about what the spec *is*. I see no downside, and significant upside, in resolving that now rather than kicking it down the road. I have read the proposal. I have it paged in. I don't want to repeat that process in three weeks, or three months, or three years. If the author wants to write a user manual entry and put that as the "proposed change spec" that would be fine with me. I'm not asking for duplicated effort. Simon On Wed, 3 Jan 2024 at 13:05, Richard Eisenberg wrote:

On Jan 3, 2024, at 7:56 AM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

If there is a consensus to accept, we can say "Accept provided you make the spec precise, and that process does not throw up any unexpected surprises". I agree that requiring a fully-precise spec for a subsequently-rejected proposal is dispiriting.

But I worry that if we kick the can down the road

- there is no mechanism to ensure subsequent precision

But there is! Code review, for the user manual entry.

- code reviewers have no spec wrt which to review the code

This can be problematic -- but reviewers should then insist that the manual entry is precise so that they can review the code.

so maybe it never gets done at all.

Simon

On Wed, 3 Jan 2024 at 12:52, Richard Eisenberg wrote:

...

On Jan 3, 2024, at 7:47 AM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

But why wait?

To reduce the burden of the proposal process. From the point of view of the proposer, putting yet more time into an as-yet-unaccepted proposal is a hoop to jump through, with uncertain outcome.

As we can observe, writing precise specifications is generally not easy. (If it were easy, then we should expect most proposals to come with one. But almost all proposals are insufficiently precise upon inspection.) I'm just trying to nudge us toward making the process easier (for us, too!).

Richard

There is no implementation-related uncertainty here. It's just a question of writing a precise spec. It's not even difficult to do!

Sometimes making the spec precise throws up unexpected wrinkles.

I'm not against postponing things where the implementation may influence details of the spec. But that's not the case here, I think.

Simon

On Wed, 3 Jan 2024 at 12:43, Richard Eisenberg wrote:

...

I agree that some aspects of this proposal are not as precise as I'd like. But actually I think we should accept before these last few details are worked out. Unless I'm mistaken, there's not a worry that the specific choices will change our minds, and the details will have to be resolved in the course of implementation. Ideally, the proposer will come back and update the proposal. However, the proposal is not the long-lasting record of the specification; the user manual is. (By contrast, the proposal is the long-lasting record of the motivation / discussion / alternatives.) So I would insist in the code-review process that the manual is fully precise, and perhaps to insist that the proposal has a note saying it will be made precise in the course of implementation -- but I don't think we need this to happen before acceptance. Sometimes the details are easier to work out during implementation and can be informed by the tiny bit of experience gained writing tests, etc.

Richard

PS: The viewpoint here -- to work out final details late -- is informed by the common practice at Jane Street. We sketch out a broad idea with a bunch of examples, but we write down the final specification only after implementing. This is so much easier, because it makes the specification process iterative with implementation.

On Jan 3, 2024, at 7:17 AM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

I'm content to accept, but only when the specification is made precise.

Simon

On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg wrote:

...

After some conversation on the ticket, I'd like to vote for acceptance here.

Richard

...

On Jan 1, 2024, at 9:46 AM, Richard Eisenberg wrote:

Yes that's true of course, but if we had a design that could cover raw strings as well, then we have one fewer quoting construct. I guess the real question is: do we need the ability to toggle between multiline and raw separately? That is, right now we have cooked single-line strings. This proposal is for cooked multiline strings, leaving raw strings for a separate proposal. But maybe we only need cooked single-line strings and raw multiline ones? That would be simpler.

I think wisdom from other languages would be helpful here. I will post on the ticket.

Richard

...

On Dec 31, 2023, at 12:04 PM, Eric Seidel wrote:

> On Dec 29, 2023, at 07:19, Richard Eisenberg wrote: > > On the other hand, I'm a little worried that this doesn't have support for raw strings. That is, even with this, there will still be some users who reach for quasiquotes for multi-line strings, if those strings contain backslashes.

I had a similar thought at first, but I think raw strings can be added independently of this proposal. So long as we are not closing the door to a future addition I think it is fine to take incremental steps.

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

The multiline string proposal looks good to me. Thanks Simon for helping polish the spec. On the meta point, I agree with Simon's position here: we should avoid giving unconditional acceptance to underspecified proposals, only to potentially discover problems later. But where a proposal is not precisely specified, it would be preferable to accept in principle (so the author is not left wondering whether the idea has a chance) and then ask and support the author to finish the spec before merging the PR. Adam On 03/01/2024 13:13, Simon Peyton Jones wrote:

But there is! Code review, for the user manual entry.

I just think that often will not happen.

I am also genuinely unclear about what the spec *is*.   I see no downside, and significant upside, in resolving that now rather than kicking it down the road.   I have read the proposal.  I have it paged in.  I don't want to repeat that process in three weeks, or three months, or three years.

If the author wants to write a user manual entry and put that as the "proposed change spec" that would be fine with me.  I'm not asking for duplicated effort.

Simon

On Wed, 3 Jan 2024 at 13:05, Richard Eisenberg mailto:rae@richarde.dev> wrote:

...

On Jan 3, 2024, at 7:56 AM, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

If there is a consensus to accept, we can say "Accept provided you make the spec precise, and that process does not throw up any unexpected surprises".  I agree that requiring a fully-precise spec for a subsequently-rejected proposal is dispiriting.

But I worry that if we kick the can down the road

* there is no mechanism to ensure subsequent precision

But there is! Code review, for the user manual entry.

...

* code reviewers have no spec wrt which to review the code

This can be problematic -- but reviewers should then insist that the manual entry is precise so that they can review the code.

...

so maybe it never gets done at all.

Simon

On Wed, 3 Jan 2024 at 12:52, Richard Eisenberg mailto:rae@richarde.dev> wrote:

...

On Jan 3, 2024, at 7:47 AM, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

But why wait?

To reduce the burden of the proposal process. From the point of view of the proposer, putting yet more time into an as-yet-unaccepted proposal is a hoop to jump through, with uncertain outcome.

As we can observe, writing precise specifications is generally not easy. (If it were easy, then we should expect most proposals to come with one. But almost all proposals are insufficiently precise upon inspection.) I'm just trying to nudge us toward making the process easier (for us, too!).

Richard

...

There is no implementation-related uncertainty here.  It's just a question of writing a precise spec.  It's not even difficult to do!

Sometimes making the spec precise throws up unexpected wrinkles.

I'm not against postponing things where the implementation may influence details of the spec.  But that's not the case here, I think.

Simon

On Wed, 3 Jan 2024 at 12:43, Richard Eisenberg mailto:rae@richarde.dev> wrote:

I agree that some aspects of this proposal are not as precise as I'd like. But actually I think we should accept before these last few details are worked out. Unless I'm mistaken, there's not a worry that the specific choices will change our minds, and the details will have to be resolved in the course of implementation. Ideally, the proposer will come back and update the proposal. However, the proposal is not the long-lasting record of the specification; the user manual is. (By contrast, the proposal is the long-lasting record of the motivation / discussion / alternatives.) So I would insist in the code-review process that the manual is fully precise, and perhaps to insist that the proposal has a note saying it will be made precise in the course of implementation -- but I don't think we need this to happen before acceptance. Sometimes the details are easier to work out during implementation and can be informed by the tiny bit of experience gained writing tests, etc.

Richard

PS: The viewpoint here -- to work out final details late -- is informed by the common practice at Jane Street. We sketch out a broad idea with a bunch of examples, but we write down the final specification only after implementing. This is so much easier, because it makes the specification process iterative with implementation.

...

On Jan 3, 2024, at 7:17 AM, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

I'm content to accept, but only when the specification is made precise.

Simon

On Tue, 2 Jan 2024 at 12:24, Richard Eisenberg mailto:rae@richarde.dev> wrote:

After some conversation on the ticket, I'd like to vote for acceptance here.

Richard

> On Jan 1, 2024, at 9:46 AM, Richard Eisenberg mailto:rae@richarde.dev> wrote: > > Yes that's true of course, but if we had a design that could cover raw strings as well, then we have one fewer quoting construct. I guess the real question is: do we need the ability to toggle between multiline and raw separately? That is, right now we have cooked single-line strings. This proposal is for cooked multiline strings, leaving raw strings for a separate proposal. But maybe we only need cooked single-line strings and raw multiline ones? That would be simpler. > > I think wisdom from other languages would be helpful here. I will post on the ticket. > > Richard > >> On Dec 31, 2023, at 12:04 PM, Eric Seidel mailto:eric@seidel.io> wrote: >> >> >>> On Dec 29, 2023, at 07:19, Richard Eisenberg mailto:rae@richarde.dev> wrote: >>> >>> On the other hand, I'm a little worried that this doesn't have support for raw strings. That is, even with this, there will still be some users who reach for quasiquotes for multi-line strings, if those strings contain backslashes. >> >> I had a similar thought at first, but I think raw strings can be added independently of this proposal. So long as we are not closing the door to a future addition I think it is fine to take incremental steps. >

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

SimonM, Vlad, The rest of the committee has expressed support for this proposal either on the ML or on SimonPJ's Google Sheet[1]. I think that is sufficient consensus to accept, but would prefer to get the full committee on record. Please take a few minutes to read the proposal and record your vote. Barring any explicit dissent, I will mark the proposal accepted next weekend. Eric [1]: https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5... On Mon, Jan 15, 2024, at 02:21, Arnaud Spiwack wrote:

On Sat, 13 Jan 2024 at 21:42, Adam Gundry wrote:

...

On the meta point, I agree with Simon's position here: we should avoid giving unconditional acceptance to underspecified proposals, only to potentially discover problems later. But where a proposal is not precisely specified, it would be preferable to accept in principle (so the author is not left wondering whether the idea has a chance) and then ask and support the author to finish the spec before merging the PR.

I agree too. I was thinking about it over the weekend: we kind of need a status to say “we pretty much know we're going to accept it, so go ahead and do the implementation, but we're still working the details out together” (I was thinking in particular of the choice of string delimiters from this proposal: it makes no material difference to the implementation what we eventually settle on. So if there are questions, we should avoid holding the implementation effort back just because we're having a discussion about what we think it best). _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee