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 <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 <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 <eric@seidel.io> wrote:
>>
>>
>>> On Dec 29, 2023, at 07:19, Richard Eisenberg <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.
>

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