[ design ] use higher-level programming abstractions

[jamesmckinna]

I'm happy with the local details of #2833 , but I'm starting (since already a while now) to be very dissatisfied with each of the underlying design decisions, notwithstanding my own refactorings which, like that one, have perpetuated suboptimal choices...

• Vector rather than Vec (but this ought to be inessential, in view of the following ... but see also Define Algebra.Definitions.RawMonoid.sum using Data.Vec.Vec #1886 on the topic)
• sum as an instance of a Foldable operation/operation on a Foldable functor.

I'm grateful to Oleg Kiselyov for drawing my attention to various invited talks by Guy Steele over the 2010s about this in the context of parallel programming in general, and FORTRAN/Fortress in particular, but also to a (much) longer history (1970s? 1980s?) in the Dijkstra et al. lineage of so-called "Eindhoven Quantifier Notation" (discussed eg here), as well as Bertot et al. "Canonical Big Operators" in Coq/SSReflect (as it then was) in the 2000s.

Shoutouts also to Johannes Waldmannn for his bracing 2018 essay on lists in haskell ...

We can, and should, do better!

Originally posted by @jamesmckinna in #2833 (comment)

Cf. the proposed v3.0 breaking changes in #2553 ...

[jamesmckinna]

As Oleg also points out to me, or at least my takeaway from discussions with him, is that the underlying software architecture in haskell-style Foldable overly commits how computation will be carried out in the Monoid instance, for any giveninstance of Foldable, precisely because such instantiation keys off the type constructor, so eg only one version of fold is definable for List... (or at least, to get alternative definitions... more code is required, rather than delegating ... elsewhere... to how monoid computation is carried out. Still scratching my head over this point!