Ongoing Thoughts on the Meta-Machine Code (MMC) Tool

It occurred to me I occasionally pick the seventh day of the seventh month to release things related
to my Meta-Machine Code tool.  The several passed years with nothing new about it have surprised me.

I considered the tool a success, a rather complete success, and decided to focus on other work.  Now
I've a much better hold on Latin for making her the target of my language work, but I've learned the
struggles of building even a decent body of words also, and I can see many years yet remaining to my
goal; I may feel like taking a break, or I could maybe more constructively use the time for English.
I can't help but realize it's been over six years since I last wrote of the insidious optimizations.

I noticed years ago how computer programming has never made me happy, and that holds true.  It takes
a fool to love these broken machines.  Only Latin has delighted me with her beauty and omnipresence.

I want to implement a language based around symbolic manipulation of doubly-linked lists, REFAL, but
that act of implementing its core matching loop befuddled me, and I found myself wanting a reference
to study for the first time in my life, finding none until recently.  Regardless, REFAL may not be a
suitable language for various reasons, so I've decided to continue with Common Lisp for my next MMC.
Ironically, I wanted to implement REFAL as an easy task, before working on implementations of Lisps.

A clear structure underlies my design, the ``Applicative State Transition system'' described by John
Backus would be one candidate, and yet I've made little effort to reach in and extract its structure
in an effort to make the tool easier to retarget at other machine codes.  I'm inclined to believe an
approach providing different generic pieces, such as the questioning and display routines, alongside
guidelines for a human written down may be the better approach, considering how wildly machine codes
differ from each other and the unique advantages a specialized tool like the MMC can make available.

A recollection system is something every MMC has so far lacked, and I want my next implementation to
have one.  This is tied to the metadata output format.  It's improper for a tool to only store state
dynamically, lost once reset in some way, though the only good way to store such additional metadata
is in most ways specific to the implementation; it would be unreasonably difficult to devise another
format but for this purpose, given the normal metadata output format is already deeply unpleasant to
implement, to the point where the latest toy MMC targeting lacks support for its very own format, so
having the tool dump its internal state with the lower language routines is the clear solution here.

The next MMC will target the 6502 machine code, and I can already feel the customization possible in
my fingers; there can be a specialized layer of the keyboard dedicated to the RIOT and TIA commands,
alongside specialized display of such instructions, both of which would make writing Atari VCS games
more pleasant.  For the purposes of code alignment to a page, it would suffice to have insertion and
deletion commands operating on either the entirety of memory, or only the current page, and the more
I envision the more I see futility in that generic approach for anything but the basics with an MMC.

I saw the model breaking down very easily with the extremely complex machine codes now common, and I
still see such.  An MMC targeting may exist for the i386 machine code and earlier, but x86_64 is far
too monstrous; it's clearly intended to be a shitty compiler target, and not written by human hands.

Even with how little I touch it, I can feel the complexity flooding about me, trying to strangle me.