Updating HLint to require using 'pure' instead of 'return'

[recursion-ninja]

Update the .hlint.yaml to require using pure instead of return. This change is intended to future-proof the code-base for the "Monad of No Return" proposal.

The changes touch a lot of the code-base and if the churn is deemed too high for negligible benefits, we can delete this pull request.

[jorisdral]

Update the .hlint.yaml to require using pure instead of return. This change is intended to future-proof the code-base for the "Monad of No Return" proposal.

The changes touch a lot of the code-base and if the churn is deemed too high for negligible benefits, we can delete this pull request.

Would return be removed from base because of the monad of no return proposal? I can't easily see that from the link you posted

[wenkokke]

This looks good to me, but it might be best to not merge this until just before we release version 1.0.0, so that there's fewer PRs impacted by this.

[wenkokke]

Update the .hlint.yaml to require using pure instead of return. This change is intended to future-proof the code-base for the "Monad of No Return" proposal.

The changes touch a lot of the code-base and if the churn is deemed too high for negligible benefits, we can delete this pull request.

Would return be removed from base because of the monad of no return proposal? I can't easily see that from the link you posted

I think the proposal is to make return a top level function rather than a member of the Monad class.

The reason to prioritise pure over return would be to not require a Monad constraint where it isn't needed. The proposal would take care of this by removing the Monad constraint from return.

However, I do support using pure over return for consistency reasons.

[recursion-ninja]

However, I do support using pure over return for consistency reasons.

I'm of a similar mind.

This looks good to me, but it might be best to not merge this until just before we release version 1.0.0, so that there's fewer PRs impacted by this.

Agreed, let's let this sit for a bit and revisit it just before or just after cutting the v1.0.0 release.

[wenkokke]

This looks good to me, but it might be best to not merge this until just before we release version 1.0.0, so that there's fewer PRs impacted by this.

Agreed, let's let this sit for a bit and revisit it just before or just after cutting the v1.0.0 release.

Let's do just before.

[recursion-ninja]

This looks good to me, but it might be best to not merge this until just before we release version 1.0.0, so that there's fewer PRs impacted by this.

Agreed, let's let this sit for a bit and revisit it just before or just after cutting the v1.0.0 release.

Let's do just before.

My preference as well 👍.

[jorisdral]

I'd probably just rip off the band-aid and it merge it 😛

[dcoutts]

Doesn't this misunderstand the Monad Of No Return proposal? It would not eliminate return, it would just make it a function that's not a method of the Monad class. So there's no need to switch from return to pure. The only compatibility thing would be to make sure any Monad instances we have (and I can't immediately think of any) don't define a custom return or >>.

[dcoutts]

The warning was implemented in GHC 8.0 and is called -Wnoncanonical-monad-instances (there are variants of this warning flag for Monoid and Fail) is included in the default warning set since GHC 9.2.

So we must be clear w.r.t. these warnings. So there's nothing to do right?

[wenkokke]

Doesn't this misunderstand the Monad Of No Return proposal? It would not eliminate return, it would just make it a function that's not a method of the Monad class. So there's no need to switch from return to pure. The only compatibility thing would be to make sure any Monad instances we have (and I can't immediately think of any) don't define a custom return or >>.

Yes, it's very much just (1) consistency, and (2) avoiding unnecessary monad constraints before that proposal lands.

[recursion-ninja]

Yes, it's very much just (1) consistency, and (2) avoiding unnecessary monad constraints before that proposal lands.

These are my thoughts as well when I added the HLint hints.

[wenkokke]

LGTM, but I wrote it. However, it took me upwards of 5 minutes to scroll past all the changes.

This review is now stale.