Refactoring Hierarchies

[jamesmckinna]

The library currently supports three 'major' hierarchies which 'organise' the content of the library

• Algebra see also Vocabulary (IsX, RawX, structures, bundles, etc) #3052 Indexing and parameters for `Algebra` (and the like) #3053
• Function which has been subject to major revision/refactoring Deprecate old function hierarchy #759 and more recently [ DRY ] Refactor Function.* to rationalise the existence of a section to a given Surjective f #2568 [ DRY ] Streamline Function.* hierarchy #2570 [ refactor ] Symmetry of Bijection as a consequence of properties of a given Surjective function #2583 [ refactor ] Redefine Relation.Binary.Definitions.Adjoint, plus knock-on Function.Consequences #2599 and [ add ] missing Function.Bundles #3069 , much of the recent ones involving the 'usual' tension between definitions-as-manifest fields in Structures/Bundles vs. Properties already explored/discussed under Algebra above
• Relation which has (mostly) been incrementally added to, rather than reorganised, but whose relationship with Function (via 'function-as'graph-relations' and 'functional-relations-as-functions' (sic) has not (yet) really been systematically explored.

There is a lot of lore/discussion on this GitHub around the design of these hierarchies, and it would be good to try and zoom out to abstract the lessons learned?

[JacquesCarette]

Always worthwhile to cite Parnas' On a "buzzword": hierarchical structure when discussions of hierarchies arise. Mostly because many so-called hierarchies have this way of transforming themselves in graphs of various sorts that have no clear hierarchical structure. We already have this between Algebra and Order.

The big lesson: hierarchies (of this sort) are always approximate and will eventually become fuzzy. This doesn't mean they are not useful! Rather like models (i.e. all of them are wrong, but some are useful.)

So if our organization helps people find stuff, as well as figure out where to submit new code, then it is likely useful. We should be careful not to take our own organization too seriously, as it will inevitably fail us.

Hmm, I wonder if we should look at other systems' organization and learn from them (i.e. both successes and failures). One of my favourite examples of such learning: even though C++ is a garbage fire, as is its template system, the design of the STL is actually quite good.