[ refactor ] Add Data.Nat.ListAction

[jamesmckinna]

Implements the 'provisional' v2.3 fix for #2553 .

Issues (summarising discussion below):

• naming+location of new module: under Data.Nat or Data.List (or elsewhere?) UPDATED to Data.Nat.ListAction
• scope of PR: minimal for v2.3, or maximal/breaking for v3.0?

NB.:

• fixes a spurious deprecation message from v2.0 in Data.List.Properties concerning sum-++-commute, but now the message is... anachronistic. Wasn't sure how to deal with this properly!

[Taneb]

I have to say, I don't like the module name... there are other monoids on Nat (e.g. (max, 0)) whose folds we'd also want to have in the same module if we have them.

[jamesmckinna]

Thanks @Taneb !

Bear in mind that I regard this PR as provisional, indeed minimal wrt not refactoring to lift out the actual Monoid abstractions as such, before a 'proper' (breaking) refactoring which will deprecate/remove this module, and all traces of the original definitions. In particular, I would want this PR only to emulate existing functionality (but product-++ seemed too tempting not to add, emphasising the need to abstract the constructions...?), rather than try to generalise it to arbitrary monoid structures arising on Nat. Perhaps that's a failure of imagination/nerve?

Eg, I could even imagine doing that generalisation (in whatever form) downstream, and then simply deprecating this module with its 'clunky' name. perhaps I even thought that would be inevitable, so either didn't care, or actively chose, to make the name 'clunky'... on a 'build one to throw away' principle...

That said, would (any of) the following be better candidate names?

• Data.Nat.MonoidAction/Data.Nat.FreeMonoidAction (a bit too general, since we're only considering the action of Nat on itself...?); it's a pity I haven't/hadn't managed to finish Add Algebra.Action.* and friends #2350 before this, but I've been trying to not let the 'perfect design' get in the way of progress... ;-), but eventually, as with Refactor Data.Nat.GeneralisedArithmetic #2446 , there ought to be a grand refactoring of all this stuff...
• Data.Nat.Monoid

Other suggestions welcome! @JacquesCarette any thoughts on this?

[JacquesCarette]

As I said elsewhere, fully agree with moving these out of where they currently are.

Hmm, why Data.Nat.* though? I was thinking of these as "special cases of List-based computation" and so under Data.List. Data.List.NatActions? [Obviously not wedded to that awkward name, but pushing things along.]

If it were in Data.Nat then I'd see it being way more general, i.e. over any foldable container.

[jamesmckinna]

As I said elsewhere, fully agree with moving these out of where they currently are.

Thanks. I had the feeling that the consensus was already 'out there' (it seems to have been a recurring issue en passant for years without anyone tackling it seriously...)

Hmm, why Data.Nat.* though? I was thinking of these as "special cases of List-based computation" and so under Data.List. Data.List.NatActions? [Obviously not wedded to that awkward name, but pushing things along.]

Interesting... but a rather different perspective to mine (although I could agree with Data.Nat.Actions, as a version of one of the choice above...) precisely because:

• as @Taneb points out, each of these (and more...) arises from a Monoid on Nat, and hence a MonoidAction of Nat on itself, ...
• and then these operations are the canonical lifting of that action to that of the Free Monoid on the carrier of Nat, by iteration (over the underlying list representation; but others are possible!) cf. the discussion on Add Algebra.Action.* and friends #2350 esp. here

So from my point of view, List is an implementation detail, when the 'real' action (sic) lies with (actions on) Nat. That's why I chose Data.Nat as the root...

If it were in Data.Nat then I'd see it being way more general, i.e. over any foldable container.

Well, indeed, but that would be a generalisation beyond the scope of this v2.3-badged PR, which I've deliberately tried to keep as minimal as possible, while opening up the design/discussion space for subsequent downstream refactorings. Besides which, I suspect (strongly) that any Foldable functor F can have its fold/foldMap definition for Monoid M factored through first the (carrier of the) free monoid on M, viz. List M followed by the iterated List-action List M → M... (this must be in the automata literature somewhere?)

[Taneb]

Do we also want to move and and or out (to something under Data.Bool if sum and product are under Data.Nat)? What about any and all?

[jamesmckinna]

Do we also want to move and and or out (to something under Data.Bool if sum and product are under Data.Nat)? What about any and all?

Well... actually no, not right now, but it might very well make sense to do so in downstream PRs? The focus of this PR, and the originating linked issue was for the 'problematic' Nat iterated actions. But happy to see the debate widened to other base types... but suggest such discussion move to #2553 ? or a fresh issue?

UPDATED: I should probably insert the (obligatory!?) warning against PR-creep!? shout out to @JacquesCarette who is usually very hot on this, but he may also have views about the Bool instances of the phenomenon...?

[jamesmckinna]

Hmmm... @Taneb 's comments (in one direction), and @JacquesCarette 's (a bit in another) suggest perhaps this should be refactored in terms of Data.List.Effectful.Foldable, but nevertheless should live under Data.Nat for sum/product, and under Data.Bool for and/or, and even all/any? As e.g Data.Nat.FoldActions?

And indeed that Effect.Foldable (or its List implementation) should also take responsibility for the CommutativeMonoid/Permutation interaction... as a downstream refactoring?

[JacquesCarette]

As I said elsewhere, agree with @Taneb that those should be moved as well. Also agree that while an issue could cover moving both sets of things, doing it in smaller PRs is more to my taste.

My feeling is indeed that this stuff belongs under Data.Nat and Data.Bool. Willing to be convinced otherwise on that aspect.

And yes, the generalizations of this (to more general containers + algebras) absolutely should be done as a separate, downstream refactor.

[jamesmckinna]

So:

• I'll rename to Data.Nat.ListAction, as some sort of median-of-three arbitration of the discussion above?
• I'll raise a separate analogous PR [ refactor ] Add Data.Bool.ListAction #2561 for Bool

Comments, as ever, welcome!

[JacquesCarette]

Data.Nat.ListAction seems a quite reasonable compromise name to me.

[JacquesCarette]

Other than property placement, the rest looks good!

[JacquesCarette]

Hmm, I think these ought to be in Data.Nat.ListAction.Properties. I still will want to have sum and product available with a decently small footprint (dependency-wise) and bundling properties with definitions defeats that.

[jamesmckinna]

And a corresponding Base module for the definitions?

Actually that tends not to be the case for eg All and Any, so perhaps not needed (certainly at this stage)?