Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

one-line define behavior #51

Open
ursi opened this issue Dec 20, 2023 · 2 comments
Open

one-line define behavior #51

ursi opened this issue Dec 20, 2023 · 2 comments

Comments

@ursi
Copy link

ursi commented Dec 20, 2023

I am not a fan of the following formatting:

(define 2list (λ (a b) (list a b)))

(define (2list a b)
  (list a b))

I would personally like to define functions this small on one line, but I also want to use the shorthand version of define. I understand whether or not it should be one line is a matter of taste, but it doesn't make sense to me that the expression that is more noisy is the one that is formatted as one line. To me that feels like a less subjective inconsistency.

@sorawee
Copy link
Owner

sorawee commented Dec 20, 2023

That's kinda funny... Your proposed behavior is what I initially implemented. Then, I got suggestions from @Metaxal and @jackfirth to unconditionally enter newline, and I made the switch in 831bb4c#diff-28c7782bc7f8926245fb8e9a590152f17a45b0c9e3dd37d043811d02b8b88476.

I want to note that it is possible for fmt to use a user-defined style. If you want to follow this approach, I'm happy to guide you through it (or add a support to make this easier). But I really do not want to have a back-and-forth change for the default style without discussion among users. If @Metaxal, @jackfirth, and you have time to discuss with others, I would appreciate that.

@Metaxal
Copy link

Metaxal commented Dec 20, 2023

I do think the current setting is good. While in principle the two cases are semantically equivalent, I see the first case as a binding between a value and a variable, which should most of the time be a on-liner, while the second case is a function definition, which for consistency should have the body below it.

I think this is a good default, but if this can be made user-adaptive that's even more awesome.

That said, in case no local consensus can be reached, we could still put this to a vote on Discourse (asking for arguments, not just "feelings"), or I would also 100% trust @sorawee to make a reasonable and informed choice.

There could also be a rule about whether to add a newline for the first case, based for example on the number of parentheses in the expression --- say, more than 2 pairs and that's a newline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants