You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
In larger codebases, it's common to have large ADTs that constantly have new options added. Some examples are:
Routes in a webapp
Command line tasks in a CLI tool
Delayed jobs that can be deserialized from a database
When developers add a new option, either as a constructor or pattern patching on the constructor somewhere, they're likely to add to the end of the list and end up with merge conflicts.
Describe the solution you'd like
It'd be nice to have a way to opt-in to sorting constructors at the data definition site, and when pattern matching on them. This makes it much less likely developers are editing around the same lines of code, and is a little cleaner.
This would have to be an opt-in at a specific site thing, since you usually wouldn't want it, and changing the order of constructors has semantic impacts.
I haven't fully considered how to handle when a constructor is repeated.
Describe alternatives you've considered
Doing this as a separate CLI tool, doing it in ormolu, just living with the conflicts, maybe some way to configure git to be less likely to conflict in these areas.
Additional context
I think such a feature would potentially go against the "avoid configuration" aspect of ormolu, but it does advance the goals of:
Writing code in such a way so it's easy to modify and maintain.
The formatting style aims to result in minimal diffs.
I don't really expect this is a high priority issue for the project. I am just implementing this now as a separate CLI tool, and figured I'd check if you all would want something inside Ormolu itself in the future.
The text was updated successfully, but these errors were encountered:
Thanks, I have also been in situations where I wanted to be able to signal the semantic irrelevance of the order of constructors/fields in the past; in which case automatic sorting would be very convenient indeed. Maybe modifiers could be used for that in the future.
Of course, automatically (i.e. without manual annotations) sorting corresponding pattern matches would require implementing project-wide name resolution, which would likely get out of hand very quickly for anything other than the simplest cases (without relying on GHC). We have a similar problem for resolving operator fixity information.
This sounds like a good idea, but there is the general problem with re-ordering things because whenever we do that the stream of comments does not get automatically reordered accordingly (this is quite difficult to do in an intelligent way). So, if we implement this naively it would cause any comments related to data constructors to be output in an unexpected order.
Is your feature request related to a problem? Please describe.
In larger codebases, it's common to have large ADTs that constantly have new options added. Some examples are:
When developers add a new option, either as a constructor or pattern patching on the constructor somewhere, they're likely to add to the end of the list and end up with merge conflicts.
Describe the solution you'd like
It'd be nice to have a way to opt-in to sorting constructors at the data definition site, and when pattern matching on them. This makes it much less likely developers are editing around the same lines of code, and is a little cleaner.
This would have to be an opt-in at a specific site thing, since you usually wouldn't want it, and changing the order of constructors has semantic impacts.
I haven't fully considered how to handle when a constructor is repeated.
Describe alternatives you've considered
Doing this as a separate CLI tool, doing it in ormolu, just living with the conflicts, maybe some way to configure git to be less likely to conflict in these areas.
Additional context
I think such a feature would potentially go against the "avoid configuration" aspect of ormolu, but it does advance the goals of:
I don't really expect this is a high priority issue for the project. I am just implementing this now as a separate CLI tool, and figured I'd check if you all would want something inside Ormolu itself in the future.
The text was updated successfully, but these errors were encountered: