Automated Resyntax fixes

[resyntax-ci]

This is an automated change generated by Resyntax.

Pass 1

Applied 4 fixes to drracket/help/bug-report.rkt

• Line 2, tidy-require: Keep imports in require sorted and grouped by phase, with collections before files.
• Line 52, cond-let-to-cond-define: Internal definitions are recommended instead of let expressions, to reduce nesting.
• Line 262, if-begin-to-cond: Using cond instead of if here makes begin unnecessary
• Line 278, cond-let-to-cond-define: Internal definitions are recommended instead of let expressions, to reduce nesting.

Applied 9 fixes to drracket/help/private/bug-report-controls.rkt

• Line 2, tidy-require: Keep imports in require sorted and grouped by phase, with collections before files.
• Line 16, provide/contract-to-contract-out: The provide/contract form is a legacy form made obsolete by contract-out.
• Line 64, let-to-define: Internal definitions are recommended instead of let expressions, to reduce nesting.
• Line 154, let-to-define: Internal definitions are recommended instead of let expressions, to reduce nesting.
• Line 256, map-to-for: This map operation can be replaced with a for/list loop.
• Line 311, map-to-for: This map operation can be replaced with a for/list loop.
• Line 327, map-to-for: This map operation can be replaced with a for/list loop.
• Line 337, unused-definition: This definition is not used.
• Line 371, let-to-define: Internal definitions are recommended instead of let expressions, to reduce nesting.

Applied 2 fixes to drracket/help/private/save-bug-report.rkt

• Line 3, tidy-require: Keep imports in require sorted and grouped by phase, with collections before files.
• Line 185, provide/contract-to-contract-out: The provide/contract form is a legacy form made obsolete by contract-out.

Summary

Fixed 15 issues in 3 files.

• Fixed 3 occurrences of tidy-require
• Fixed 3 occurrences of let-to-define
• Fixed 3 occurrences of map-to-for
• Fixed 2 occurrences of provide/contract-to-contract-out
• Fixed 2 occurrences of cond-let-to-cond-define
• Fixed 1 occurrence of unused-definition
• Fixed 1 occurrence of if-begin-to-cond

[sorawee]

Personally I would write it like this:

(define (<f> field field-name)
  ...)

(<f> name (string-constant bug-report-field-name))
(<f> summary (string-constant bug-report-field-summary))

It's going to be difficult to come up with the name <f> though...

[jackfirth]

Agreed, but yeah there's no easy way to automatically pick a name for <f> here.

Unless... I suppose... one could use an LLM to do that...

No. I will not walk down that dark road.

[rfindler]

a for loop still seems preferable to the for-each, tho?

[sorawee]

Does DrRacket still even have the bug report functionality? If not, can they just be removed?

[rfindler]

Can we ask that (provide (contract-out always be on two lines?

[sorawee]

Which "two lines" are you talking about? Is it how in each clause, the identifier should be in one line, and the corresponding contract should be in another line? That can be adjusted by changing the formatter of contract-out. But wouldn't this look better?

(provide (contract-out
          [foo (-> number? number?)]
          [bar (-> number? number?)])))

Or are you talking about how you always want:

(provide 
 (contract-out 
  [foo ...]))

instead?

[rfindler]

The latter. The provide and the contract-out on two separate lines.

It may be better to think of this as something that should happen because future lines'll have less leftward drift just in general, or may it is better to special case these two? Or maybe this is an unreasonable request? :)

[jackfirth]

I also think it should always look like the latter.

[sorawee]

Or maybe this is an unreasonable request?

It's totally reasonable! I'm simply trying to pinpoint what exactly is the general change that you want. I understand how you want the above, specific program to be formatted. But what about the below program -- which one do you prefer?

(A)

(provide foo
         bar
         (contract-out 
          [baz ...]))

vs

(B)

(provide 
 foo
 bar
 (contract-out 
  [baz ...]))

I'm mentioning this because my understanding is that:

(provide foo
         bar
         baz)

is the usual format for provide. So (A) seems to be more consistent with the usual format? But if that is the case, then it feels weird to me that we want:

(provide foo
         bar
         (contract-out 
          [baz ...]))

but at the same time also don't want

(provide (contract-out 
          [baz ...]))

One possibility to satisfy all constraints might be to have a rule like "if contract-out is the only subform of provide, then provide and contract-out should be in different lines." That would work, but I'm not sure if that's what you had in mind.

[jackfirth]

I prefer B in the options you provided, though I'm not thrilled about it when it happens.

[sorawee]

So @jackfirth's proposed rule is that if contract-out is one of subforms of provide, then always enter a newline after provide. That definitely could be done if we all agree with it.

[rfindler]

I agree; option B is my preference too. Another option is to split the provide into two provides when there is a contract-out form. Maybe that's a bad idea, tho.

[sorawee]

Something like this? sorawee/fmt#81

which would affect the format of:

• https://github.com/racket/racket/blob/218c28e4dfce1d3920f6079d14c19d1df68c0287/racket/collects/racket/random.rkt#L5-L10
• https://github.com/racket/racket/blob/218c28e4dfce1d3920f6079d14c19d1df68c0287/pkgs/net-lib/net/private/rr-srv.rkt#L6-L11
• https://github.com/racket/racket/blob/218c28e4dfce1d3920f6079d14c19d1df68c0287/racket/collects/racket/struct.rkt#L4-L9
• https://github.com/racket/racket/blob/218c28e4dfce1d3920f6079d14c19d1df68c0287/racket/collects/syntax/parse.rkt#L17-L26

The file test-contract-out.rkt.out contains some example output.

[rfindler]

LGTM