preparation for GHC 9.10 - fix a bunch of warnings

I will wait a little bit before screening these
as the volume of CPP/new pragmas is a bit annoying.

4 patches for repository darcs-unstable@darcs.net:/opt/darcs/screened:

patch fdc1ead351ed6211c4dbad71cf8115df702c2177
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sun Jun  2 22:57:44 BST 2024
  * Fix incorrect imports of PrimOf(..)

patch 52aa45deca3a74f51b217493a2504ddbbf22449b
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sun Jun  2 23:02:36 BST 2024
  * GHC 9.10 fix - need to import Prelude for ~

patch 2f3ceb2e4045909cc09f174d9e6c765590f9feb5
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sun Jun  2 23:05:02 BST 2024
  * suppress new warning about NE.unzip

patch a1bcf7b62740d6542e5c88caa63c8f3cb5c75b13
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sun Jun  2 23:05:15 BST 2024
  * manage migration of foldl' to the Prelude

Attachments

• fix-incorrect-imports-of-primof____.dpatch
• patch-preview.txt

* GHC 9.10 fix - need to import Prelude for ~

I have a hard time to believe src/Darcs/Patch/RepoPatch.hs is the only 
place we use the ~ (type) operator. Can we move this conditional to 
Darcs.Prelude, too?

The other changes are fine.

* suppress new warning about NE.unzip

Could you explain what this is about? I read your comments but I still 
don't understand the issue.

> I have a hard time to believe src/Darcs/Patch/RepoPatch.hs is the 
> only place we use the ~ (type) operator. Can we move this
> conditional to Darcs.Prelude, too?

It didn't import Darcs.Prelude before (and now only does so
conditionally).

It's the only place that both uses ~ *and* didn't import Darcs.Prelude.

> Could you explain what this is about? I read your comments but I 
> still don't understand the issue.

NE.unzip is currently polymorphic over the container type, i.e. it'll
work with any Functor, not just Data.List.NonEmpty.

It's being changed to being monomorphic:
https://github.com/haskell/core-libraries-committee/issues/86

and there's a new warning on *any* usage - monomorphic or polymorphic:
https://github.com/haskell/core-libraries-committee/issues/258

These two pragmas are the only way I've found to stay warning free
on all GHCs. We could also switch to Data.Functor.unzip but
(a) that doesn't exist on older GHCs and (b) it's actually
better to use the specialised one as it makes the types clearer and
might have a more efficient implementation.

Thanks for the explanations, understood.

In the case of src/Darcs/Patch/RepoPatch.hs I would slightly prefer 
importing Darcs.Prelude unconditionally and instead suppress warnings 
about redundant imports in that module.

Your changes that introduced the NonEmpty stuff to avoid warnings came 
when I was not around to comment so it's not my place to complain now. 
Still, for the record, I am not in favour of these developments. For 
one, NonEmpty seems to be a moving target as we clearly see now. Also, 
focussing on these few low-hanging fruits is pointless. It's been ages 
since I actually stumbled over a "Prelude.head" pattern match error in 
Darcs itself and if I actually did it would probably be an easy fix. 
Look at the output of a

  grep -r 'error "' src

to get a feel for how many of our own functions are partial. And note 
that due to design mistakes from a looong time ago, we have lots of 
places where we throw exceptions from supposedly pure code even though 
they are clearly not "impossible".

Anyway, feel free to screen. We can always improve the fixes later on.

Updated to avoid CPP in Darcs.Patch.RepoPatch

4 patches for repository darcs-unstable@darcs.net:/opt/darcs/screened:

patch fdc1ead351ed6211c4dbad71cf8115df702c2177
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sun Jun  2 22:57:44 BST 2024
  * Fix incorrect imports of PrimOf(..)

patch 2f3ceb2e4045909cc09f174d9e6c765590f9feb5
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sun Jun  2 23:05:02 BST 2024
  * suppress new warning about NE.unzip

patch a1bcf7b62740d6542e5c88caa63c8f3cb5c75b13
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sun Jun  2 23:05:15 BST 2024
  * manage migration of foldl' to the Prelude

patch 43385c49f7aeba61cf5bf195ab385727206c0225
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Mon Jun  3 14:53:59 BST 2024
  * GHC 9.10 fix - need to import Prelude for ~

Attachments

• fix-incorrect-imports-of-primof____.dpatch
• patch-preview.txt

All fine, except one final remark / possible follow-up to

  * suppress new warning about NE.unzip

Do we perhaps want to add -Wno-unrecognised-warning-flags everywhere i.e. in 
darcs.cabal? Might ease the process of suppressing particular warnings in 
the future. OTOH, a misspelled warning flag might silently be ignored, 
causing confusion.

Personally I'd prefer to keep it as tightly scoped as possible.

An alternative approach might to be pick a single GHC version to keep
warning-free (typically the most recent but maybe the one before that
when it's quite new) and not worry about warnings in other versions.
It might reduce the gyrations to keep everything clean.

> Personally I'd prefer to keep it as tightly scoped as possible.

Yes, I tend to agree.

> An alternative approach might to be pick a single GHC version to keep
> warning-free (typically the most recent but maybe the one before that
> when it's quite new) and not worry about warnings in other versions.
> It might reduce the gyrations to keep everything clean.

Sounds like a reasonable approach. Shouldn't be too hard to hack into the 
CI configuration.

> Also, focussing on these few low-hanging fruits is pointless. It's 
> been ages since I actually stumbled over a "Prelude.head" pattern 
> match error in Darcs itself and if I actually did it would probably be 
> an easy fix.

The main reason to become warning-free on this is so that future uses
of head are discouraged where possible.

A secondary reason is to keep our codebase roughly aligned with
current Haskell conventions.

My criticism was more about the way the Haskell ecosystem develops. I agree that in the long run we don't have a choice but to adapt. I wouldn't necessarily do that pro-actively, but that's a minor style difference and no big deal. Still, I'd say let us make these adaptions with the minimum amount of disruption.