[ refactor ] fix #2865 for v2.4

[jamesmckinna]

This is one approach to #2865 but having committed this, I see a couple of possible pain points:

• what exactly should the CHANGELOG be, given the somewhat underspecified entries from Add various relations over non-empty lists #2862 , and that this is strictly speaking 'just' a revision of an existing v2.4 set of changes?
• what exactly should the names be? (REVISED; see most recent commits; I'd like to re-use the name satisfiable, but I guess that might be breaking... sigh))

If nothing else, it serves to make concrete the discussion of the issue #2865 and any candidate solution. I've updated the issue with my latest thoughts on the matter, so maybe it's worth making this DRAFT until that discussion shakes out?

[JacquesCarette]

I'm not against this change (and would be willing to change my comment to an approve), but I do find Any.any⇒satisfiable quite redundant. (I'm fine with the change wrt + and - superscripts, that is more coherent.)

I'm not sure of the balance between having names spelled out in full what the function does and using more contextual information (it's in the Any module!) wrt saying what the function does.

[jamesmckinna]

Thanks @JacquesCarette I'll update the PR in line with my new thinking as discussed on #2865 ... Aaargh! re-using a name, but only one introduced by #2862 so it's OK to:

• rename satisfied to satisfiable in Data.List.Relation.Unary.Any
• rename correspondingly in Data.List.NonEmpty.Relation.Unary.Any, and as that was introduced only under Add various relations over non-empty lists #2862 for v2.4, that seems OK!?
• double-down on my reasoning on the original issue, and introduce in Data.List.Relation.Unary.Any
  • satisfiable⁺ : Satisfiable P → Satisfiable (Any P)
  • satisfiable⁻ : Satisfiable (Any P) → Satisfiable P

Arguably the last two additions are... potentially confusing, but I think they are consistent with our style-guide policies.

[jamesmckinna]

Are we (collectively) sure that this is not a breakingchange? If so, then merge, but a brainworm of doubt is worrying away at me... so if not, we'd better postpone to v3.0?

I reread the discussion on #2865 (much of it my own ;-)), and looked reasonably carefully at the blame... and Data.List.Relation.Unary.Any seems to have added satisfied and satisfiable at least before @MatthewDaggitt 's #1379 in v1.5. So, I think we can't blithely rebind the name satisfiable for bare Lists (even though it is safe to do so for the less developed instances under NonEmpty and Fresh). Sigh. But I think that we should do so...

So, I'll revise the opening question and ask instead:

• make these changes/additions to NonEmpty and Fresh for v2.4, with a note that we need also to make the consistent, but breaking, change for v3.0 for bare List
• postpone the uniform consistent change until v3.0

Advice welcome before we unwittingly merge this as-is with two approvals!?

[jamesmckinna]

This unfortunately introduces a clash with the old definition attached to this name, at L93-L94 below, so while consistent with the rest of the PR, introduces a breaking name change for List.

[JacquesCarette]

I think your path forward seems to be the one most consistent with our current policies.

[jamesmckinna]

I think your path forward seems to be the one most consistent with our current policies.

My addled brain wasn't able to work out which you think the "path forward" actually is:

• (non-breaking) don't change the name in List, but do so everywhere else?
• (breaking) or do so everywhere?

[JacquesCarette]

non-breaking for now, wait for 3.0 for breaking.

[jamesmckinna]

non-breaking for now, wait for 3.0 for breaking.

OK, I think that this is now ready, and correct according to such policy/rubric ;-)