Re^2: A proper name for is_sorted function that can check more than just sorting order?

Exactly right, the problem is broken down via reduce and then some characterization. Ordering can be ascending/descending, strict/non-strict, involve numeric/string compare, etc.

However, the example given is a test for gaps or discontinuities rather than ordering. This, and the other topic relating to Testing, makes me think the concept OP is looking for might be invariant.

Comment on Re^2: A proper name for is_sorted function that can check more than just sorting order? Download Code

Replies are listed 'Best First'.
Re^3: A proper name for is_sorted function that can check more than just sorting order? by Dallaylaen (Chaplain) on Dec 25, 2017 at 23:02 UTC
In fact the "concept OP is looking for" is called dependent type theory. However, this isn't even remotely implementable in Perl. Possibly in Scala or Haskell, definitely in more advanced languages like Idris. Not sure about Perl6. So in the absence of "you cannot do it in a way that breaks invariants" types, a mixture of runtime/unit tests that can be fine-tuned on accuracy<------>speed scale makes for a poor but workable substitute. In my opinion, anyway, but I'm going to put it to the test the hard way.	[reply]
Re^4: A proper name for is_sorted function that can check more than just sorting order? by Anonymous Monk on Dec 26, 2017 at 20:26 UTC
Why not OO framework then? Getters/setters, methods all in one place with internal logic and consistency checks as required. What problem is this that cannot be abstracted and subdivided into parts?	[reply]
Re^5: A proper name for is_sorted function that can check more than just sorting order? by Dallaylaen (Chaplain) on Dec 28, 2017 at 10:32 UTC
Object-orientation and type checking protect from certain type of errors, but they don't impose specific behavior on class methods. Runtime assertions and to a lesser extent unit-tests guard invariants. Unit-tests ensure (or, rather, try hard to disprove) the fact that in certain predictable cases the software behaves exactly as predicted. There are also design-by-contract frameworks (like Class::Contract) that do all of the above, however at a performance cost, plus it's a bit of take it or leave it. One cannot say "ok, we had a bug yesterday, so I'm adding a contract wrapper to this sub so we can avoid it in the future". All different, each serves its own purpose...	[reply]