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

[Simon Peyton Jones]

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

>
>
> On Jan 3, 2024, at 7:56 AM, Simon Peyton Jones <
> simon.peytonjones at 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 <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/e96153f0/attachment.html>