feat(Haskell): More commutative parents and signatures #488

Merged

wetneb merged 1 commit from maralorn/mergiraf:feat-haskell-more-commutative-parents-and-signatures into main

2025-07-22 07:22:39 +02:00

maralorn commented

2025-07-09 23:08:31 +02:00

Contributor

I was glad to see more Haskell support in 0.12. That motivated me to think about more commutative parents and I found quite a lot.

I am wondering a bit about comments. Operationally they do of course commute, should I generally add them to restricted_to_groups? I guess generally programmers would be very against permuting comment lines but I assume mergiraf will only do that for new lines anyway, won’t it?

I was glad to see more Haskell support in 0.12. That motivated me to think about more commutative parents and I found quite a lot. I am wondering a bit about comments. Operationally they do of course commute, should I generally add them to restricted_to_groups? I guess generally programmers would be very against permuting comment lines but I assume mergiraf will only do that for new lines anyway, won’t it?

🎉 1

maralorn added 1 commit

2025-07-09 23:08:32 +02:00

feat(Haskell): More commutative parents and signatures

/ test (pull_request) Successful in 35s

Details

980eb67ad4

wetneb commented

2025-07-10 00:20:23 +02:00

Owner

Thanks a lot! That's an impressive list!

I am wondering a bit about comments. Operationally they do of course commute, should I generally add them to restricted_to_groups? I guess generally programmers would be very against permuting comment lines but I assume mergiraf will only do that for new lines anyway, won’t it?

I recommend against including comments. In fact, I often specify .restricted_to_groups() for the sole purpose of excluding comments.
The correct placement of comments is generally necessary for them to be understood correctly, and because the grammar allows them to appear anywhere, mergiraf isn't very good at putting them in sensible places when doing a commutative merging. I even opened #467 to exclude comments from commutative merging by default, even without restring to a specific group.

Did you consider adding a few tests to demonstrate the commutative merging? I trust you it works, but adding the tests would make sure the functionality stays there in the future (for instance if the grammar changes).

Thanks a lot! That's an impressive list! > I am wondering a bit about comments. Operationally they do of course commute, should I generally add them to restricted_to_groups? I guess generally programmers would be very against permuting comment lines but I assume mergiraf will only do that for new lines anyway, won’t it? I recommend against including comments. In fact, I often specify `.restricted_to_groups()` for the sole purpose of excluding comments. The correct placement of comments is generally necessary for them to be understood correctly, and because the grammar allows them to appear anywhere, mergiraf isn't very good at putting them in sensible places when doing a commutative merging. I even opened #467 to exclude comments from commutative merging by default, even without restring to a specific group. Did you consider adding a few tests to demonstrate the commutative merging? I trust you it works, but adding the tests would make sure the functionality stays there in the future (for instance if the grammar changes).

wetneb approved these changes

2025-07-21 22:10:23 +02:00

wetneb left a comment

Owner

I'm thinking about merging this without tests by default. #489 would likely help to improve the default coverage of such changes.

maralorn commented

2025-07-21 22:25:46 +02:00

Author

Contributor

Ah, sorry. I was still planning to write the tests, but I didn’t find the time. You can ofc. merge without them. I don’t think I would write a test which would find invalid merges introduced by this. They would only serve to make sure I actually implemented the right thing.

👍 1

wetneb commented

2025-07-21 22:27:06 +02:00

Owner

That's totally fine! If you ever want to add some, you're of course welcome to make another PR for it.