public apologia

The important classical Greek meaning of the word "Apologia" is
"defense" (in the juridical sense).

Sorry I've been slow with merges lately but I entered a planning phase
as the apartment move was finishing up.  The "FEATURE PLANS" are one
symptom and there's a bunch more interesting stuff that will follow
shortly.  I hit upon a few key ideas recently and my mind is exploding
with their implications.  There's an incredible wealth of (nicely
inter-related/complementary) "easy plays" that answer the question
"what should happen to arch next".  I'm just trying to orient myself
to the new ideas before I resume hacking.

I'm sorry there's a pending (non-exploited, minor-threat) security
patch.   I'm sorry that my hackerlab--devo branch is apparently
currently busticated.   I'm prioritizing and these trade-offs are, in
my judgement, for the benefit of all.

Arch is kinda cool these days but.... really.... my excuse for taking
merges and so forth slow these few weeks is that the planning I'm
doing is going to make Arch _really_ cool in the months to come.

Oh, and this is going to the Pika list, too.

Here's the deal with that (archers may be interested too, in case they
aren't a subset of the pikers).:

The non-eval-related part of the Pika run-time systems is within
putting-distance of done.  To complete the job and have a standard
R5RS Scheme is just finishing up the elbow-grease tasks left on the
run-time plus implementing "eval".  To provide "eval" we need two
things: a compiler and a VM.

There are notes in the Pika tree about an assembly language for the
VM, and a register model of the VM, but they are incomplete.

I've started a new project (the "frthr" category in my archive) that
will, among other things, close that gap, but in a clever (I hope)
way.

What I'm building there might be described as "forth (postscript,
really) meets Scheme but with the GC optional".  It's a
postscript-style forthish-vm whose symbolic _machine_ code is, in and
of itself, a very handy high-level programming language (stackish and
RPN-ish, no less) and who's machine code is also an easy target for a
Scheme compiler.

The neat thing is that the forth-ish VM is defined such that GC is
optional:  implementations can choose to provide only reference
counting instead.

It would be horrible to have to use Scheme surface syntax and
constructs to write programs for a reference-counting implementation,
but the symbolic machine language of the VM is (intended to be) a
convenient language for writing for implementations that might not
have graph-tracing GC.

I think that the (soon to be published) frthr VM trumps Mono and
Parrot.  There are many reasons why and I've given up trying to
summarize them and will resort to just answering questions after the
release to try to defend my hypothesis.

I intend to use frthr machine language, presuming a reference-counting
implementation, to implement new tla commands and the cluster of
functionality we've been calling itla.   frthr's forth-like symbolic
machine language will be the "official" extension language of tla.

Beyond tla: graph-tracing-GC-providing implementations of frthr will
be suitable hosts for a portable Pika Scheme implementation that
targets such implementations in its (rather trivial) compiler.
The existing work on the Pika run-time can be extended to become a
frthr (full GC) VM.

Meanwhile, the frthr model (including ref-count-only implementations)
is easy to extend with a wealth of super-cool
object-oriented-programming features, specialized
"virtial-coprocessors", support for massive parralism, and so on.
Frthr is, I predict, the machine language that Scheme originally
wanted to be.

And the smallest and simplest implementations, such as tla will use,
will fit in just a few thousand lines of code.

"knock on wood",
-t