Almost got it. I need some help understanding what
noop_delete_prev_paren_pair is intended to do.
Please realize that I'm trying to implement its behavior in a completely different algorithmic setting (I am using zipper tree structures, not vectors of tokens), and so I don't want advice on how to read the current implementation's code. I'd like to have a description of its intention, not the code.
Now it's stated above it "deletes the previously defined parenthesis pair". Does that mean
- it will remove the first previously-defined empty subtree it finds
- it will "lift up" the contents of the first previously defined subtree it finds, moving its contents up a level to the parent subtree
- like the previous, but it deletes the contents of the subtree
Now as I said my algorithm is using Clojure
zipper constructs to build these trees dynamically, not translating into an intermediate encoding that then needs to be parsed like the original algorithm. When the translator function encounters a
noop_delete_prev_paren_pair gene, there are no "close" or "open" parentheses, just a current cursor position in the tree.
For example, suppose we're in the following state, building a program tree. Don't worry about how we got here, or what is on the various stacks right this second. Just tell me what you think the correct outcome for executing
noop_delete_prev_paren_pair would be, OK?
program: '( 1 2 ( 3 ( ) ) 4 ( 5 ( 6 ) ( 7 ) * ) )
;; * indicates the cursor position
outcome #1: '( 1 2 ( 3 ) 4 ( 5 ( 6 ) ( 7 ) * ) )
outcome #2: '( 1 2 ( 3 ( ) ) 4 ( 5 ( 6 ) 7 * ) )
outcome #3: '( 1 2 ( 3 ( ) ) 4 ( 5 ( 6 ) * ) )
Or is it some other outcome I'm not seeing?
When I've figured this out, I think I'm done here. The new code will build Push programs from arbitrary gene tuples, using the
:silent fields already present in the Clojush codebase. Rather than being so dangerously coupled to the codebase, it takes as an argument a
branch-map, which is a map that has the information currently hidden throughout the Clojush interpreter in the meta-data. That way, the translator can be easily extended for new instructions added to the interpreter, or it can build a
branch-map programatically by interrogating the interpreter it will be running on, or it can be easily modified for testing on the fly.