Multiple EXITs and structure 
Author Message
 Multiple EXITs and structure

"Good/Bad" programming is in the eye of the beholder.

However, the virtues of a well-structured, readable and maintain-
able program need not be repeated here. I have generally found
the structure

        : choices       cond_A  IF do_A  EXIT  THEN
                        cond_B  IF do_B  EXIT  THEN
                          .......
        ;

to be more readable than a bunch of nested IF...ELSE...THENs

        : choices'      cond_A  IF  do_A   ELSE
                        cond_B  IF  do_B   ELSE
                          .......
                        THEN ... THEN
        ;

which is also equivalent to the CASE...OF structure.

Note, BTW, that they are not logically equivalent unless the
conditions are mutually exclusive. That is, A and B can't be
simultaneously true. This is a pitfall that probably has caused
more program bugs than any other single source (including spaghetti
code).

We often must write innately complex programs that translate
many possible inputs to many possible outputs, perhaps with
time- or context-dependence as complicating factors.

The difficulty in keeping straight the logical structure of
nested IFs is the chief reason I favor multiple EXITs, or
jump tables/state machines, as techniques for hiding complexity.

--
Julian V. Noble



Sun, 10 Jan 1999 03:00:00 GMT  
 Multiple EXITs and structure


Quote:
>"Good/Bad" programming is in the eye of the beholder.

>However, the virtues of a well-structured, readable and maintain-
>able program need not be repeated here. I have generally found
>the structure

>    : choices       cond_A  IF do_A  EXIT  THEN
>                    cond_B  IF do_B  EXIT  THEN
>                      .......
>    ;
>to be more readable than a bunch of nested IF...ELSE...THENs

>    : choices'      cond_A  IF  do_A   ELSE
>                    cond_B  IF  do_B   ELSE
>                      .......
>                    THEN ... THEN
>    ;

>which is also equivalent to the CASE...OF structure.

        Have mentioned it before, I'll point out that:

        : choices''
                if{             cond_A ?THEN do_A
                        ELSE    cond_B ?THEN do_B
                        ...
                        ELSE    do_Z
                }endif

        ;

automates the fixing of the multiple branch targets by
dropping a marker in the op-sys stack at the beginning
that lets }endif know when to stop fixing branch targets.
I've always had a mild preference for automating tasks
like that.

--
Virtually,

Bruce R. McFarling, Newcastle, NSW



Mon, 11 Jan 1999 03:00:00 GMT  
 Multiple EXITs and structure

Quote:

> "Good/Bad" programming is in the eye of the beholder.

> However, the virtues of a well-structured, readable and maintain-
> able program need not be repeated here. I have generally found
> the structure

>    : choices       cond_A  IF do_A  EXIT  THEN
>                    cond_B  IF do_B  EXIT  THEN
>                      .......
>    ;

> to be more readable than a bunch of nested IF...ELSE...THENs

>    : choices'      cond_A  IF  do_A   ELSE
>                    cond_B  IF  do_B   ELSE
>                      .......
>                    THEN ... THEN
>    ;

> which is also equivalent to the CASE...OF structure.

> Note, BTW, that they are not logically equivalent unless the
> conditions are mutually exclusive. That is, A and B can't be
> simultaneously true. This is a pitfall that probably has caused
> more program bugs than any other single source (including spaghetti
> code).

Doggone it! I knew there was something wrong with that when I
wrote it. What I _meant_ to say was, "Although they are logically
equivalent, they depend on the order of evaluation unless the
conditions are mutually exclusive."  Sorry, it was late and I
was tired from (creatively) working on expense accounts.

The remark about the pitfall stands, however.

--
Julian V. Noble



Tue, 12 Jan 1999 03:00:00 GMT  
 Multiple EXITs and structure


: > "Good/Bad" programming is in the eye of the beholder.
: >
: > However, the virtues of a well-structured, readable and maintain-
: > able program need not be repeated here. I have generally found
: > the structure
: >
: >  : choices       cond_A  IF do_A  EXIT  THEN
: >                  cond_B  IF do_B  EXIT  THEN
: >                    .......
: >  ;
: >
: > to be more readable than a bunch of nested IF...ELSE...THENs
: >
: >  : choices'      cond_A  IF  do_A   ELSE
: >                  cond_B  IF  do_B   ELSE
: >                    .......
: >                  THEN ... THEN
: >  ;
: >
: > which is also equivalent to the CASE...OF structure.
: >
: > Note, BTW, that they are not logically equivalent unless the
: > conditions are mutually exclusive. That is, A and B can't be
: > simultaneously true. This is a pitfall that probably has caused
: > more program bugs than any other single source (including spaghetti
: > code).

: Doggone it! I knew there was something wrong with that when I
: wrote it. What I _meant_ to say was, "Although they are logically
: equivalent, they depend on the order of evaluation unless the
: conditions are mutually exclusive."  Sorry, it was late and I
: was tired from (creatively) working on expense accounts.

That's *exactly* why I like the Dijkstra guarded commands!  An IF aborts
if none of the conditions are true, so if your code hits a case you
didn't plan for, you get informed and execution terminates!  Let me
summarize the structures, since I brought this up.  A conditional is
written

        if  f1 ==> x1 |
            f2 ==> x2 |
            f3 ==> x3 |

            .
            .
            .

        fi

This is read "if f1 is true then do x1, if f2 is true then do x2," etc.
As I noted above if none of the conditions are true, the construct
aborts.  If more than one is true, the implementation selects one of
them to execute in a manner not known to or controlled by the
programmer.

The corresponding loop is written

        do f1 ==> x1 |
           f2 ==> x2 |
           f3 ==> x3 |

           .
           .
           .

        od

If none of the conditions is true, this becomes a no-operation.  If one
or more of the conditions is true, the implementation selects one of
them in a manner not known to or controlled by the programmer, executes
the corresponding action, then branches back to the "do" for another
pass.  The loop keeps going until none of the conditions is true.

Here's a simple example: the GCD of two integers:

        do x > y ==> x := x - y |
           y > x ==> y := y - x
        od

When x = y, the loop is done and both x and y are equal to the GCD of
the original x and y!

This looks like it would be easy to do in ANS Forth with "origs" and
"dests".  You'd have to rename DO and IF, of course, since they have
defined uses already.  I may get a chance to try this with hForth over
the weekend; I'll post the code here if I do.

--

Actually, for their size, elephants don't smell all that bad.

"The only thing we have to fear is fear itself -- and, of course, the
boogeyman."  Pat Paulsen



Tue, 12 Jan 1999 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. multiple exit points in a loop?

2. Multiple exits

3. Is using multiple EXITs bad programming practice?

4. Exit codes in $? multiples of 256

5. Multiple arguments, structured arguments [ LONG ] (was Re: dyadic functions)

6. Process multiple files same structure?

7. Process multiple files of the same structure

8. Opening a multiple file structure at run-time

9. Multiple Structure Inheritance

10. Multiple Inheritance and Dynamic Class Structures

11. multiple event structures

12. using multiple event structures polling for panel closing event

 

 
Powered by phpBB® Forum Software