property-based testing

I suppose there are worse names than property-based proving, and it fits well enough. I'll still call it by the name I've already chosen.

On the other hand: are you familiar with cellular automata? The tables remind me of that.

Yes. Well, the most general such implementations are simple table indexing, so I can certainly see the relation.

It's very freeing, to be able to prove a program works, without thinking about it.

The difference is that the approach in the current article attempts to over-formalize the mathematical proof for mechanical processing, which is unfortunately the curse of most (all?) "computer-assisted proof systems" devised to date.

So, no thoughts on my method, then?

Consider a more interesting way to prove those two list algorithms: Consider using a very small memory space of linked-lists, so that every possibility may be enumerated; prove every possible combination be correct; prove the algorithm doesn't depend on the memory space, which can be done by construction; and then prove the size of the memory space be irrelevant. This can be done mechanically, to good success. Machines can easily compare billions of values; they should be used like this to prove things more often.

I've decided upon a different method of proving software correct, one which doesn't require nearly so much thought. I for now call it Tabular Programming; this article applies it to Roman numerals:
http://verisimilitudes.net/2022-01-31

The basic idea is that a great many things can be represented as a table access, but not everything; by using very simple composition rules, we can use such tables to represent infinity, however; thus the amount of code and computation is reduced to its bare minimum, and a hacker need only check the tables and the few, small rules to prove correctness. Such programs can trivially be made to have constant time and constant memory properties. Proving correctness can also be done mechanically, by simply comparing tables for equality, sparing the hacker thought for better things, and this mechanism is easily-understood.

For append and reversal, these methods are overkill; it clearly suffices to prove proper operation for empty list arguments, and then arbitrary lists, and a specialized calculus would make this much more concise. I've also read the LISP 1.5 programmer's manual, and don't recall McCarthy needing such things therein; the truth was obvious, the truths were the definitions.

Program correctness will come from correctly composing correct components, and I question how much intelligence truly be needed for this. I'll cease writing before I drone on further.

From my obtuse angle, it looks like Australians have finally figured out that there's no strategic edge to this brain-damaged approach of adding piles of machine-edible annotations that no one else will read. Dude, specifications are meant to be consumed first by humans and then, maybe, as an afterthought, verified by machines. There's absolutely no point in rewriting the program as a spec in yet another broken programming language: it's expensive as hell and, owing mainly to the intrinsic property of computers of being systematically misusable, it yields very rarely and very little.

So in response, instead of addressing this first, you're embarrassing yourself by putting the matter yet again! on the to-do list. What can I say, watching how this obtuseness will destroy you in the not-even-all-that-long term will be sorta fun to watch... as fun as anything can be in the post-covid times.