move to consistent instruction behavior

[Vaguery]

There are really only a few types of instruction outcome:

• change in interpreter state
• restructure existing stack/binding contents
• produce items to stack

One of the excuses given for having instructions immediately push results to stack is “inefficiency”, but clearly these folks mean “inefficiency of execution” not “inefficiency of people reading or writing instruction definitions”.

I think Klapaucius should err always towards the latter, and address the former with smart programming practices. So I want to consider deeply rewriting the DSL so it always returns a tulle of items to :exec. If the result is always a tuple (even if empty), then we can construct more formal type signatures for instructions, and make better headway towards functional programs and functions as first-order types.

As for execution inefficiency, it seems pretty clear we could (with clearer, simpler type labeling) do “quick dealing” of long runs of literal sin returned tuples. For example, if I’m serious and make :scalar-yank return a tuple of all the :scalar values from the whole stack to :exec, then a quick pass over the contents before processing by the Router can help simplify and speed things up dramatically. If a code block only contains numbers, we can append it in the appropriste way tkntje number stack.

The other potential concern would be special routing, such as for :code or :error or :print. Well, these can be skipped, but honestly they’re already managed. There is QuotedCode, and I think the routers are already set to handle :error items. That leaves :print and return… which are trivial.

[Vaguery]

So here's the plan:

1. all single return values are pushed (naked) onto :exec
2. all multiple return values including combinators are pushed onto :exec as code blocks; so for example, :boolean-dup pushes a code block containing two :boolean values onto :exec
3. instructions like :X->code will wrap the :X item in a :quoted block and push to :exec

Yes, there will be many more steps of the interpreter. That's actually a feature, since it helps put large-scale transformative instructions like stack-yankers into complexity perspective.

[Vaguery]

In progress

[Vaguery]

Replaced (and undone) by #175