On May 2, 9:42 pm, Jonah Thomas
cavtel.net> wrote:> Bruce McFarling
netscape.net> wrote:>> If you have something that demands a complex control flow structure,
>> then it is even more essential then ever to be able to test the
>> control flow.
>> Say they are SNARE PITCH instead of CATCH THROW
>> Here, you are de-localizing the control flow. One part is in this
>> word, which does a PITCH, and the other part is over there in the word
>> that called a word that called a word that contained that word, which
>> does the SNARE.
>> This can easily, in other words, be worse than a GOTO, because it is
>> delocalized with the destination entirely context dependent.
>> And you have really snarled up the process of bench testing the
>> complex control flow structure.
> It depends. What it's done is to factor the control flow away from the
> action.
The first point to make is ... not necessarily. It no more
intrinsically factors the control flow away from the action than the
the decision tables Mikael Nordman has. With a decision table, the
"action" can be to test further down one particular branch, or the
"action" could be to return an index to an action in a table.
However, it also anti-factors in an important sense. That is, the
individual components that go into the word that is SNAREd can *only*
go into a word that is SNAREd ... they are not free standing factors
in their own right.
So you have a calling word that is a test harness in order to allow
the smaller factor to work, and test that, and then it is taken out of
the test harness and defined into a higher level word in the decision
structure, and that is placed in the test harness, and so on. And if
control flow has been factored away from action, that is over and
above any dummy for the actions, if you are nailing down the control
flow first.
On the other hand, if you have a decision table defining word that
creates a decision table that can slot in as the action of a higher
level decision table, there's no need for the sequence of test
harnesses ... just run each decision table as it is compiled for test
cases. And each decision table is a potential factor in any word, not
simply in a word that SNAREs the result.
> This only works when the control flow can be a collection of
> nested IFs or if it involves loops, you loop until you get a success
> that causes you to exit the loop. It provides a single exit. And when
> you exit you can provide a token like a throw code.
So this part is entirely independent of whether you implement the
complicated decision structure with PITCH/THROW, with nested IF and
BEGIN/UNTIL loops, or with decision tables.
Indeed, you can easily define words that have the stack picture of:
( u0*i flag -- u1*i flag )
... that leave immediately if the flag is true, and proceed to test if
the flag is false, returning the appropriate flag, that provide an
automatic short-circuit OR like the decision table ... if the stack
contents under the flag is an index into an xt-table, then that also
allows the decision to be factored out. Those words have the pattern:
: /foo/ ( index flag -- index' flag' ) IF TRUE EXIT THEN
( index ) ... ( index' flag' ) ;
... I called that a slider, so that the pattern is [/slide/]
: [/slide/] POSTPONE IF
POSTPONE TRUE POSTPONE EXIT POSTPONE THEN
; IMMEDIATE
They fit comfortable into UNTIL loops, allowing a sequence of tests to
repeat, normally with side-effects, until somewhere in the loop the
end-state is reached, the execution slides through the remainder of
the loop, and exits.
