[ghc-steering-committee] Proposal #569: multiline string literals; Rec: accept
Adam Gundry
adam at well-typed.com
Sat Jan 13 20:41:59 UTC 2024
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 <rae at richarde.dev
> <mailto:rae at richarde.dev>> wrote:
>
>
>
>> On Jan 3, 2024, at 7:56 AM, Simon Peyton Jones
>> <simon.peytonjones at gmail.com <mailto: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
>> <mailto:rae at richarde.dev>> wrote:
>>
>>
>>
>>> On Jan 3, 2024, at 7:47 AM, Simon Peyton Jones
>>> <simon.peytonjones at gmail.com
>>> <mailto: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 <mailto: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
>>>> <mailto: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 <mailto: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 <mailto: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 <mailto:eric at seidel.io>> wrote:
>>>> >>
>>>> >>
>>>> >>> On Dec 29, 2023, at 07:19, Richard Eisenberg
>>>> <rae at richarde.dev <mailto: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.
>>>> >
>>>>
--
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
More information about the ghc-steering-committee
mailing list