On 2 May 2007 15:41:53 -0700
Bruce McFarling
netscape.net> wrote:
> On May 2, 2:48 am, Jonah Thomas
cavtel.net> wrote:>> OK. I occasionally run into situations that seem to demand complex
>> control flow structures.
>
> 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. 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 when you test the control flow, for any particular set of inputs the
question is whether you provide the right outputs on the stack and also
the right token. That isn't hard to test at all. And then you want to
know whether your chosen action in that case expects the particular
stack items that you provide, and whether it does the right things. This
factoring need not be a bad thing at all.
I'll try to say that clearer. When you have a complex set of choices to
decide which action to take, and a list of actions -- it might be just
fine to separate out the choices from the actions. You do SNARE to start
the routine that makes the choice. Once the choice is made, you can for
example have a jump table of actions. You can test the actions
completely independent of the choices you make to decide which action to
take. You can test the choices independent of the actions resulting from
those choices. You must check that each PITCH provides the right stack
items for its chosen action -- that's hardly harder than having the code
for the action right there. You'd want to put a stack picture beside the
PITCH . I expect this would be easier than getting all that right in a
maze of IF ELSE THENs. It provides the same sorts of convenience as EXIT
but far more flexibly.
SNARE PITCH wouldn't simplify all complex control-flow problems because
it only works when you go through a decision process to choose one
action and return. If you want to repeat the decision for every item in
a loop then the SNARE will have to be inside the loop.
> Mikael Nordman's "test until success" table is the opposite. No matter
> how much complexity is embedded in that table, its all there in that
> one place, and once the table has been compiled, its straightforward
> to test it every which way but loose. If the testes are nested in
> arbitrary ways, then some successes lead to a different test until
> success table, matching the nesting of the decision problem itself.
Nested tables don't result in everything in one place. But if the
choices make *sense* then each table can make sense at its own level of
abstraction, and it won't lead to bugs.
SNARE PITCH looks simple and convenient but it may be a specialised tool
that wouldn't get used enough to justify learning it. We already have
lots of tools like THIRD which occasionally make things easier but which
are used so seldom that people are likely to forget they're available
the times they're most useful.
