[ghc-steering-committee] Proposal #569: multiline string literals; Rec: accept

[Simon Peyton Jones]

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 <rae at richarde.dev> wrote:

>
>
> On Jan 3, 2024, at 7:47 AM, Simon Peyton Jones <
> simon.peytonjones at 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 <rae at 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 <
>> simon.peytonjones at 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 at 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 at 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 at seidel.io> wrote:
>>> >>
>>> >>
>>> >>> On Dec 29, 2023, at 07:19, Richard Eisenberg <rae at 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 at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240103/91bd59d5/attachment.html>