The Meta-Machine Code (MMC) Tool Implemented in a Spreadsheet

Less code is always better, at the very least almost all of the time.  One may haggle over extremely
complicated definitions which save little space compared to others, but it's generally true that the
simpler and more succinctly a system may be described the better.  I regularly recall the article by
ngnghm describing platforms, not applications, and the ability to meaningfully compose greater work:
http://ngnghm.github.io/blog/2015/12/25/chapter-7-platforms-not-applications

There are certain parts of the MMC I never bothered implementing, because perfecting them would be a
mild bother and mostly wasted on an imperfect version of the system: these parts are range movement,
allowing a segment of code to be relocated; a recollection system, to forgive mistakes; and, in some
targetings, full support for the tool's own metadata format.  Each of these parts is simple, but the
need to tweak such for each targeting, and apathy for lesser versions, meant I left them unfinished.

A spreadsheet is the single best example of data-flow programming.  Anyone who understands data-flow
programming can understand a spreadsheet and, more importantly, anyone who doesn't understand it can
still understand a spreadsheet.  I first noticed the resemblance between the MMC and a spreadsheet's
interface; the MMC is row-based, but the rows are arranged into uniform columns, and this similarity
was a hint that the two designs were alike in other important ways.  I've since decided to implement
targetings of the MMC using models of spreadsheets, and began with one particularly simple: GNU SES,
a spreadsheet mode included in GNU Emacs' default installation.  I've long yearned to free all of my
programming from GNU Emacs and so found this to be more than a little ironic, but GNU SES appears to
be weak and unsuited to a particularly good version of this, regardless.  I'm not certain whether or
not I'll be able to contort LibreOffice Calc well enough to suit me, but it would be one of the best
options; one advantage of implementing tools as data for another is allowing other people to use it.

A forthcoming article will show the minor mode I've written for GNU SES; I'm currently struggling to
customize the key mapping and some other things properly, as I've not previously written a mode.  An
important issue is organizing the names for data in a way suited to the spreadsheet, so that it will
handle all changes without any further action, which seems to be more difficult with certain models.

The power in a platform lies not only in what needn't be done, but what can be permitted implicitly.
I'd like for the 6502 targeting to have a field for cycle counts, and it's immoral for a man to need
to sum numbers shown to him by a machine which can add them by itself.  To allow this under a normal
targeting requires me to anticipate its need, to design an interface for interacting with it, and to
implement it.  In a spreadsheet, summing a column of numbers beginning and ending on certain rows is
the prime purpose of the program and needs no special interface; similarly, I separate documentation
from code in part because I believe such separation to be proper, but the spreadsheet will only need
use of finite columns, and thus the user would be free to add more for any purposes he can envision.

I've long mulled over writing an MMC targeting in REFAL, because the language was made to manipulate
doubly-linked lists, but I suppose a spreadsheet is an alternative view, and likely on far superior.
.