Re: Expressive Case Statements (was: Software landmines)

Re: Expressive Case Statements (was: Software landmines)

[Brian Rogoff]

On Tue, 1 Sep 1998, Richard D Riehle wrote:
>  I realize this was supposed to be about optimizations. But this is the
>  year of changing the subject what with tails wagging dogs, etc. Ted's
>  mention of "case statements" reminds me of a problem with which I have
>  been struggling for quite a while; one for which I finally cry, "Help!"
> 
>  There is a language called COBOL in which the ANSI 1995 standard 
>  introduced a fascinating construct called the EVALUATE statement. It
>  is the most powerful form of a case statement I have seen in any
>  programming language. More powerful than Ada. More powerful than Eiffel.
>  More powerful than C++ or Java. 

Unfortunately, I don't COBOL, but I think I can read your case statement
below, and I wonder if the following, in Objective Caml, does the trick:
> 
>  One of the forms the EVALUATE statement (there are several options), 
>  allows the programmer to directly represent a decision-table for a
>  set of conditions with syntax such as,
> 
>         EVALUATE condition-1 ALSO condition-2 ALSO condition-3 
>                              
>            WHEN TRUE ALSO TRUE ALSO FALSE 
>                           PERFORM 
>                               some action-stub statements
>                           END-PERFORM
>            WHEN TRUE ALSO FALSE ALSO FALSE
>                           PERFORM 
>                               some action-stub statements
>                           END-PERFORM
>            WHEN FALSE ALSO FALSE ALSO TRUE
>                           PERFORM 
>                               some action-stub statements
>                           END-PERFORM
>         END-EVALUATE

let get_val b1 b2 b3 =  
	match (b1, b2, b3) with 
	| (true, true, false) ->
	perform1	
	| (true, false, false) ->
	perform2
	| (false, false, true) ->
	perform3
	| (_,_,_) ->  perform_default;;

I think ML style pattern matching is pretty powerful compared to Ada's,
and Prolog's even more so. 

> In business data process software, such as banking and insurance, the
> decision table is useful for representing complex sets of conditions
> and their corresponding actions.  In military command and control
> systems we also see these kinds of complex condition sets.
> 
> It is certainly easy to represent any set of conditions with a sequence
> of if ... elsif statements but I am seeking something else.  What I have
> been trying to accomplish is some generalized algorithm in Ada that 
> allows me to design a package that approximates the power of the EVALUATE
> statement in COBOL.  Some of the new features of Ada 95 such as generic
> formal package parameters, access to subprogram, etc. have helped a
> little, but ...

As I'm sure you know, you need to create mapping functions to an
enumerated type or something similar in order to use Ada's case statement. 
I don't think there is a general solution, you can't even use tags in 
case statements. Yeah, I prefer ML for its more powerful pattern matching,
but Ada has her charms too. I guess we Ada fans will have to do this by 
hand; we also have to do it by hand if we want to translate our close 
cousin language VHDL's case statement to Ada.

-- Brian

Re: Expressive Case Statements (was: Software landmines)

[Tucker Taft]

Richard D Riehle (laoXhai@ix.netcom.com) wrote:

: ...
:         EVALUATE condition-1 ALSO condition-2 ALSO condition-3 
:                              
:            WHEN TRUE ALSO TRUE ALSO FALSE 
:                           PERFORM 
:                               some action-stub statements
:                           END-PERFORM
:            WHEN TRUE ALSO FALSE ALSO FALSE
:                           PERFORM 
:                               some action-stub statements
:                           END-PERFORM
:            WHEN FALSE ALSO FALSE ALSO TRUE
:                           PERFORM 
:                               some action-stub statements
:                           END-PERFORM
:         END-EVALUATE

: ...
: It is certainly easy to represent any set of conditions with a sequence
: of if ... elsif statements but I am seeking something else.  What I have
: been trying to accomplish is some generalized algorithm in Ada that 
: allows me to design a package that approximates the power of the EVALUATE
: statement in COBOL.  

What about:
    type Cond_Array is array(Positive range <>) of Boolean;
  ...
    declare
        Conds : constant Cond_Array := 
	  (condition-1, condition-2, condition-3);
    begin
        if Conds = (true, true, false) then
	    ...
        elsif Conds = (true, false, false) then
	    ...
	elsif Conds = (false, false, true) then
	    ...
	end if;
    end;

This certainly seems close enough, and captures the decision table
nature of the solution.  This doesn't use any "fancy" Ada 95 features.
In fact, it doesn't use any Ada 95 features at all!

If you require a case-statement solution, the following general pattern
would work:

    type Cond3 is (FFF, FFT, FTF, FTT, TFF, TFT, TTF, TTT);
    Cond3_Map : array(Boolean, Boolean, Boolean) of Cond3 is
      (((FFF, FFT), (FTF, FTT)), ((TFF, TFT), (TTF, TTT)));
  ...

    case Cond3_Map(condition-1, condition-2, condition-3) is
        when TTF =>
            ...
        when TFF =>
            ...
        when FFT =>
            ...
        when others => null;
    end case;

: ...
: Richard Riehle
: richard@adaworks.com
: http://www.adaworks.com

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Expressive Case Statements (was: Software landmines)

[Robert I. Eachus]

In article <6shit4$eaj@dfw-ixnews5.ix.netcom.com> Richard D Riehle <laoXhai@ix.netcom.com> writes:

 > It is certainly easy to represent any set of conditions with a sequence
 > of if ... elsif statements but I am seeking something else.  What I have
 > been trying to accomplish is some generalized algorithm in Ada that 
 > allows me to design a package that approximates the power of the EVALUATE
 > statement in COBOL.  Some of the new features of Ada 95 such as generic
 > formal package parameters, access to subprogram, etc. have helped a
 > little, but ...

     type Truth_Table_3 is (False_False_False, False_False_True,...
                                 True_True_True); 
     function To_TT3(Cond_1,Cond_2,Cond_3 : Boolean := False)
                                            return Truth_Table_3;

     case To_TT3(Condition_1, Condition_2, Condition_3) is
       when True_True_False  => some_action_stub_statements;
       when True_False_False => some_action_stub statements2;
       when False_False_True => some_action_stub statements3;
       when others => null;
     end case;

     Obviously you want the various truth table types in a package,
and you have several ways of writing the bodies of the conversion
functions.  I prefer:

     function To_TT3(Cond_1,Cond_2,Cond_3 : Boolean := False) 
                                        return Truth_Table_3 is
     begin
       return Truth_Table_3'Val(Cond_1'Pos * 4 + Cond_2'Pos * 2 + Cond_3);
     end To_TT3;

     I think I'd write a program to crank out the type declarations
though.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Expressive Case Statements (was: Software landmines)

[Richard D Riehle]

In article <6sh487$lnq$1@nnrp1.dejanews.com>,
	dennison@telepath.com wrote:

>Being one of those goto-phobes as well a big fan of case statements, this
>subject interests me. I assumed the relatively strict rules on case
statement
>predicates were specifically formulated so that they could be implemented
as
>jump-tables. Is that not the case? Is there anything that I can do to my
case
>statements to help the compiler out a bit?
 
 I realize this was supposed to be about optimizations. But this is the
 year of changing the subject what with tails wagging dogs, etc. Ted's
 mention of "case statements" reminds me of a problem with which I have
 been struggling for quite a while; one for which I finally cry, "Help!"

 There is a language called COBOL in which the ANSI 1995 standard 
 introduced a fascinating construct called the EVALUATE statement. It
 is the most powerful form of a case statement I have seen in any
 programming language. More powerful than Ada. More powerful than Eiffel.
 More powerful than C++ or Java. 

 One of the forms the EVALUATE statement (there are several options), 
 allows the programmer to directly represent a decision-table for a
 set of conditions with syntax such as,

        EVALUATE condition-1 ALSO condition-2 ALSO condition-3 
                             
           WHEN TRUE ALSO TRUE ALSO FALSE 
                          PERFORM 
                              some action-stub statements
                          END-PERFORM
           WHEN TRUE ALSO FALSE ALSO FALSE
                          PERFORM 
                              some action-stub statements
                          END-PERFORM
           WHEN FALSE ALSO FALSE ALSO TRUE
                          PERFORM 
                              some action-stub statements
                          END-PERFORM
        END-EVALUATE

In business data process software, such as banking and insurance, the
decision table is useful for representing complex sets of conditions
and their corresponding actions.  In military command and control
systems we also see these kinds of complex condition sets.

It is certainly easy to represent any set of conditions with a sequence
of if ... elsif statements but I am seeking something else.  What I have
been trying to accomplish is some generalized algorithm in Ada that 
allows me to design a package that approximates the power of the EVALUATE
statement in COBOL.  Some of the new features of Ada 95 such as generic
formal package parameters, access to subprogram, etc. have helped a
little, but ...

.... so far, I am not satisfied with the result of my own efforts. I am 
curious if anyone else has approached the problem of decision tables
in this way.  Is there a generalized solution in Ada with the expressive
power of the COBOL EVALUATE?  This would seem to be such a useful 
reusable component that I would be surprised if no one has done it yet.

Richard Riehle
richard@adaworks.com
http://www.adaworks.com
   

Re: Expressive Case Statements (was: Software landmines)

[Richard D Riehle]

In article <EACHUS.98Sep1193718@spectre.mitre.org>,
	eachus@spectre.mitre.org (Robert I. Eachus) wrote:

  as a solution to the problem I posed about truth tables,

>     type Truth_Table_3 is (False_False_False, False_False_True,...
>                                 True_True_True); 
>     function To_TT3(Cond_1,Cond_2,Cond_3 : Boolean := False)
>                                            return Truth_Table_3;
>
>     case To_TT3(Condition_1, Condition_2, Condition_3) is
>       when True_True_False  => some_action_stub_statements;
>       when True_False_False => some_action_stub statements2;
>       when False_False_True => some_action_stub statements3;
>       when others => null;
>     end case;

  This comes close to what I am seeking.  Now I need to read it over
  and see it I can make it more general.  

  Thanks for your ideas, Robert.  

>     Obviously you want the various truth table types in a package,
>and you have several ways of writing the bodies of the conversion
>functions.  I prefer:
>
>     function To_TT3(Cond_1,Cond_2,Cond_3 : Boolean := False) 
>                                        return Truth_Table_3 is
>     begin
>       return Truth_Table_3'Val(Cond_1'Pos * 4 + Cond_2'Pos * 2 + Cond_3);
>     end To_TT3;
>
> I think I'd write a program to crank out the type declarations
> though.

  I need to code this as a compilable example and see if I can 
  generalize it.  As it is, it appears to satisfy the special 
  case of a three-valued table. 
 
  The example coded in a functional language looked very good, but
  that is not Ada.  

  Thanks again.

  Richard

Re: Expressive Case Statements (was: Software landmines)

[Richard D Riehle]

In article <EyMJzp.MB8.0.-s@inmet.camb.inmet.com>,
	stt@houdini.camb.inmet.com (Tucker Taft) wrote:

>Richard D Riehle (laoXhai@ix.netcom.com) wrote:
  [snipped away Richard's lengthy posting with the problem]

>What about:
>    type Cond_Array is array(Positive range <>) of Boolean;
>  ...
>    declare
>        Conds : constant Cond_Array := 
>	  (condition-1, condition-2, condition-3);
>    begin
>        if Conds = (true, true, false) then
>	    ...
>        elsif Conds = (true, false, false) then
>	    ...
>	elsif Conds = (false, false, true) then
>	    ...
>	end if;
>    end;
>
>This certainly seems close enough, and captures the decision table
>nature of the solution.  This doesn't use any "fancy" Ada 95 features.
>In fact, it doesn't use any Ada 95 features at all!

 Now the problem is formulating the actual conditions.  As you know,
 in the decision table there is the condition stub, in which we 
 formulate conditions such as A > B, Z = C, etc.  The rule stub where
 we specify the T, T, F, etc, the action stub where we specify the
 possible set of actions, and the Rule Actions where we can indicate
 which actions corrspond to which rules.  

 The solution you show is a good start.  I still need a more generalized
 model for the condition stub.  Perhaps this is simply a set of functions
 that return Boolean results mapped to the array of booleans.  This seems
 easier to state than to convert into a generalized model.  Then again,
 it may be that I am, 1) too close to the way it is solved in another
 language, 2) so obtuse that it its simplicity does not jump right out
 at me, or 3) both 1 and 2.

 I will look this over more closely and see if I can turn it into a
 generalized solution that corresponds to what I am seeking.  

 Thanks for your input, Tucker.  You do have a way of helping us set
 out on a more interesting path of discovery.

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com

 

Re: Expressive Case Statements (was: Software landmines)

[Robert I. Eachus]

In article <6si98q$fbo@sjx-ixn4.ix.netcom.com> Richard D Riehle <laoXhai@ix.netcom.com> writes:

  > I need to code this as a compilable example and see if I can 
  > generalize it.  As it is, it appears to satisfy the special 
  > case of a three-valued table. 

   Hmmm.  When I was thinking about your challenge, I did try a "more
generalized approach.  Basically you need a modular type, some
aliases, and to make sure your case expressions are static:

     type Truth_Table is mod 8;

     True1: constant Truth_Table := 128;
     True2: constant Truth_Table :=  64;
     True3: constant Truth_Table :=  32;
     True4: constant Truth_Table :=  16;
     True5: constant Truth_Table :=   8;
     True6: constant Truth_Table :=   4;
     True7: constant Truth_Table :=   2;
     True8: constant Truth_Table :=   1;
     False: constant Truth_Table :=   0;

     function TT (Cond_1, Cond_2, Cond_3, Cond_4, Cond_5, Cond_6,
                  Cond_7, Cond_8 : Boolean := False) return Truth_Table;
     ...

     case TT(Condition_1,Condition_2,Condition_3) is

       when False | True1 =>  Do_Something;
       when True1 + True2 =>  Do_Something_Else;
       ...
       when others => Do_Nothing;

     end case;


     If works, but I think that the notation becomes confusing.  In fact
it becomes VERY confusing if you use the boolean operators.  For
example,  "True1 and True2" evaluates to False, and "True1 or True3"
evaluates to the same value as TT(True, False, True).  Of course, you
could replace the modular type with an integer type to disallow such
bogusity.

     So I thought the approach I sketched yesterday was better.  You
would need a package with probably five types, covering two to six
booleans.  (You could go higher, but I've never done a 128 value
table, and I think I've only gone to six choices once.)  The
complexity is all in the package--the user just needs to know how many
choices he has.

    However, there is one additional thing I remembered on the way
home.  I have used this approach before, and ended up using an
enumeration type that was:

   type Truth_Table_3 is (NNN, NNY, NYN, NYY, YNN, YNY, YYN, YYY);
-- could have used T and F, but Y and N fit better.

   function All_False renames NNN;
   function True_3 renames NNY;
   ...
   function All_True renames YYY;

or:

   All_False: constant Truth_Table_3 := NNN;
   ...

whichever you prefer.

   Basically, you can have constant or renaming declarations which
allow you to name the cases in a way that makes sense locally.  With
bigger truth tables, that turns out to be a big help.  In fact
thinking about it, I almost always reify the states of a truth table
by using an enumeration type specific to that particular table.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Expressive Case Statements (was: Software landmines)

[Robert I. Eachus]

In article <35ECDA3F.3372@atlas.otago.ac.nz> "Dr Richard A. O'Keefe" <ok@atlas.otago.ac.nz> writes:

  > Concerning decision tables, the EVALUATE statement in COBOL,
  > and Robert I. Eachus's suggestion for doing them in Ada,
  > I don't know what the COBOL standard says about EVALUATE,
  > but there was one point about decision tables which seems
  > to have been missed:

  >   - as well as the condition *combinations* being complex,
  >   - the condition *elements* may be complex, and
  >   - you don't want to evaluate them if you don't have to...

  True, but from experience decision tables are not for situations
where evaluating all the decision variables is potentially harmful.
There are often cases where you nest decision tables because some
predicates should only be evaluated in some cases.  Too many don't
cares should also be taken as an indication that you have merged
tables that should be separate.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Expressive Case Statements (was: Software landmines)

[Tom Moran]

>  condition       condition entry 
>        stub                stub
>         ------------------------------------------
>         c1  | T   T   T   T   F   F   F   F        
>         ----|--------------------------------------         
>         c2  | T   T   F   F   F   F   T   T
>         ----|--------------------------------------         
>         c3  | T   F   T   F   F   T   T   F
>         ----|-------------------------------------         
>         ==========================================
>         A1  | X   X   X                   X               
>         ----|--------------------------------------    
>         A2  |     X   X 
>         ----|--------------------------------------    
>         A3  | X       X            X
>         ----|--------------------------------------    
>      Action               Action Entry
>        Stub                   Stub
  Does this mean that in case T-T-T you want to perform *both* actions
A1 and A3, and that case T-F-F (et al) can never occur (ie, raises
Program_Error or something)?  Or am I misunderstanding this notation?

Re: Expressive Case Statements (was: Software landmines)

[Tom Moran]

Another question: Are all possibilities handled separately, or are
there "don't cares" that merge, eg
  when FF =>
  when FT =>
  when TF | TT =>
And one assumes, of course, that the code in each branch is relatively
small and not worth making 2**N children of an abstract tagged with  a
separate "procedure calculate" for each one.

Re: Expressive Case Statements (was: Software landmines)

[Dr Richard A. O'Keefe]

Concerning decision tables, the EVALUATE statement in COBOL,
and Robert I. Eachus's suggestion for doing them in Ada,
I don't know what the COBOL standard says about EVALUATE,
but there was one point about decision tables which seems
to have been missed:

  - as well as the condition *combinations* being complex,
  - the condition *elements* may be complex, and
  - you don't want to evaluate them if you don't have to.

The kind of thing I'm getting at here is

   DO DECISIONTABLE (CHEAP_TEST, COSTLY_TEST)
   CASE (TRUE, -): FOO;
   CASE (-, TRUE): BAR;
   CASE (FALSE, FALSE): UGH;
   END;

(sorry about the syntax, I've never used EVALUATE in COBOL,
and while I _have_ used 'DO DECISIONTABLE' in a version of
Burroughs Algol -- Laurence Chiu, are you out there? --, it
has been a _long_ time)

That can be implemented as

  IF CHEAP_TEST THEN FOO ELSE
  IF COSTLY_TEST THEN BAR ELSE UGH;

Robert Eachus's suggestion _always_ evaluates _all_ the
condition elements even if some of them happen not to be
needed in a particular case.  (We're talking about the
difference between 'and' and 'and then' here.)

It fits into the general rule of 'helping the compiler to
help you by giving it a clue'.

There's a body of old literature about how to compile decision
tables, even including the 'extended' decision tables where you
list the condition elements and the action elements and can not
only select _which_ action elements are done when but also in
what order.

Decision tables became unfashionable; I never understood why.
A lot of this stuff surface in CS again in higher-level languages
like Clean, where

   case (cheap, costly) of
   (True, _) -> foo
   (_, True) -> bar
   _         -> ugh

would very probably be compiled just as I suggested above; it's a
_lazy_ functional language.

If I had a problem where decision tables paid off, I would write
a preprocessor to take decision table syntax and spit out Ada.
I would try to add some semantics to the decision table language
to check if the tables made sense...

I'd also investigate a Prolog-in-Ada package, like the one that
was originally part of ANNA.  Or calling CLIPS from Ada.

Re: Expressive Case Statements (was: Software landmines)

[Matthew Heaney]

tmoran@bix.com (Tom Moran) writes:

> Are the conditions in such a decision table always boolean, or might
> they be any enumerated type?

They can be any enumerated type.  For example, if color = (red, green,
blue), and boolean = (true, false), and that's 6 combinations:

color  R  R  G  G  B  B

bool   T  F  T  F  T  F

> Do you care if the compiler checks that you have branches for all
> possibilities (as in a case statement, but not in an elsif list)?

I find that it's better to consider all the _possible_ combinations,
then prune away the ones that don't make sense.  (See my other post for
a decision table analysis of a loop predicate.)

Re: Expressive Case Statements (was: Software landmines)

[Matthew Heaney]

"Dr Richard A. O'Keefe" <ok@atlas.otago.ac.nz> writes:

> Decision tables became unfashionable; I never understood why.

Me neither.  It's a mental tool every programmer should have in his
toolbox.  

Re: Expressive Case Statements (was: Software landmines)

[Tom Moran]

Are the conditions in such a decision table always boolean, or might
they be any enumerated type?
Do you care if the compiler checks that you have branches for all
possibilities (as in a case statement, but not in an elsif list)?

Re: Expressive Case Statements (was: Software landmines)

[Richard D Riehle]

In article <35ecc519.37879718@SantaClara01.news.InterNex.Net>,
	tmoran@bix.com (Tom Moran) wrote:

>Are the conditions in such a decision table always boolean, or might
>they be any enumerated type?
>Do you care if the compiler checks that you have branches for all
>possibilities (as in a case statement, but not in an elsif list)?

  Tom,

  Good question.  The model I am considering is,

       condition       condition entry 
        stub                stub
         ------------------------------------------
         c1  | T   T   T   T   F   F   F   F        
         ----|--------------------------------------         
         c2  | T   T   F   F   F   F   T   T
         ----|--------------------------------------         
         c3  | T   F   T   F   F   T   T   F
         ----|-------------------------------------         
         ==========================================
         A1  | X   X   X                   X               
         ----|--------------------------------------    
         A2  |     X   X 
         ----|--------------------------------------    
         A3  | X       X            X
         ----|--------------------------------------    
      Action               Action Entry
        Stub                   Stub

  With COBOL this can be expressed with a statment that maps directly
  to the picture.  This turns out to be wonderfully convenient when
  trying to determine how to convey the needs of a user to those of
  a programmer and vice versa.   I certainly know how to code this in
  a variety of brute-force methods.  I am trying to determine if there
  is some way I can generalize this as a class or as an Ada package
  that gives the programmer the same simplicity of expression I can
  achieve with the COBOL EVALUATE statement. 

  Richard Riehle
  richard@adaworks.com
  http://www.adaworks.com        

Re: Expressive Case Statements (was: Software landmines)

[Richard D Riehle]

In article <35ECDA3F.3372@atlas.otago.ac.nz>,
	"Dr Richard A. O'Keefe" <ok@atlas.otago.ac.nz> wrote:

[ snipped a little bit of preamble

>  - as well as the condition *combinations* being complex,
>  - the condition *elements* may be complex, and
>  - you don't want to evaluate them if you don't have to.

   Absolutely true statement.  The number of combinations is
   exponential.  When you get beyond three conditions the 
   problem can become unwieldy.  This is the beauty of decision
   tables.  Ridiculous choices can be identified immediately and
   discarded.  The COBOL Evaluate statement allows you discard those
   inappropriate choices in a readable and well-documented syntax.

>Decision tables became unfashionable; I never understood why.

  I'm with you.  I once used a language called LOBOC (COBOL spelled
  backwards) that was based on decision tables.  Unfortunately, one
  also had to embed Assembler (Autocoder for those of you ancient
  enough to remember it) in the code.  The decision tables greatly
  enhanced our ability to reason about complex relationships between
  choices and to rule out those that were nonsense.  They also forced
  us to ask questions about the possibility of a certain set of 
  situations ever occurring.  This helped with error management.

 [snipped some interesting code from Clean]

>If I had a problem where decision tables paid off, I would write
>a preprocessor to take decision table syntax and spit out Ada.
>I would try to add some semantics to the decision table language
>to check if the tables made sense...

 This is a possibility.  I am more interested to see how this could
 be best designed, for greatest expressibility, in an Ada package
 specification.  

>I'd also investigate a Prolog-in-Ada package, like the one that
>was originally part of ANNA.  Or calling CLIPS from Ada.

 ANNA keeps coming up in these discussions lately.  Hmmmmmmmm.


 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com
 

Re: Expressive Case Statements (was: Software landmines)

[Richard D Riehle]

In article <35eda0d0.15935137@SantaClara01.news.InterNex.Net>,
	tmoran@bix.com (Tom Moran) wrote:

>>  condition       condition entry 
>>        stub                stub
>>         ------------------------------------------
>>         c1  | T   T   T   T   F   F   F   F        
>>         ----|--------------------------------------         
>>         c2  | T   T   F   F   F   F   T   T
>>         ----|--------------------------------------         
>>         c3  | T   F   T   F   F   T   T   F
>>         ----|-------------------------------------         
>>         ==========================================
>>         A1  | X   X   X                   X               
>>         ----|--------------------------------------    
>>         A2  |     X   X 
>>         ----|--------------------------------------    
>>         A3  | X       X            X
>>         ----|--------------------------------------    
>>      Action               Action Entry
>>        Stub                   Stub
>  Does this mean that in case T-T-T you want to perform *both* actions
>A1 and A3, and that case T-F-F (et al) can never occur (ie, raises
>Program_Error or something)?  Or am I misunderstanding this notation?

    The decision entries are read vertically as you note.  In those
    situtations where there are no action entries, no action is 
    required.  With the COBOL Evaluate statment one would only code 
    "when" statements for those actions that had entries.  It is, 
    of course, legal to have an "others" condition which accomodates 
    those decision entries for which there are no valid actions.

    Richard Riehle
    richard@adaworks.com
    http://www.adaworks.com

Re: Expressive Case Statements (was: Software landmines)

[Fergus Henderson]

eachus@spectre.mitre.org (Robert I. Eachus) writes:

>"Dr Richard A. O'Keefe" <ok@atlas.otago.ac.nz> writes:
>
>  > Concerning decision tables, the EVALUATE statement in COBOL,
>  > and Robert I. Eachus's suggestion for doing them in Ada,
>  > I don't know what the COBOL standard says about EVALUATE,
>  > but there was one point about decision tables which seems
>  > to have been missed:
>
>  >   - as well as the condition *combinations* being complex,
>  >   - the condition *elements* may be complex, and
>  >   - you don't want to evaluate them if you don't have to...
>
>  True, but from experience decision tables are not for situations
>where evaluating all the decision variables is potentially harmful.

Why is it potentially harmful?  Do you mean because of the efficiency
problem in such cases, or is there some other reason?

I think Richard O'Keefe was pointing out an advantage of languages
which support lazy evaluation.  So unless there is some justification
other than the efficiency problem, your statement above should be
"from experience in languages which do not support lazy evaluation, ...",
since in languages which *do* support lazy evaluation, decision tables
can work fine as far as efficiency is concerned even in situations in
which evaluating all the decision variables is potentially harmful. 
Richard's Clean program was an example of this.

>There are often cases where you nest decision tables because some
>predicates should only be evaluated in some cases.  Too many don't
>cares should also be taken as an indication that you have merged
>tables that should be separate.

Do you mean that to apply in general, or only to languages such as Ada
which don't support lazy evaluation?

If you mean it to apply in general, what's the justification?

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

Re: Expressive Case Statements (was: Software landmines)

[Dale Stanbrough]

Richard D Riehle wrote:

">I'd also investigate a Prolog-in-Ada package, like the one that
 >was originally part of ANNA.  Or calling CLIPS from Ada.
 
  ANNA keeps coming up in these discussions lately.  Hmmmmmmmm."
 

If people want to use a cleaned up version of the Prolog-in-Ada
packages that originated from ANNA, i have them on my homepage at...


   http://goanna.cs.rmit.edu.au/~dale/software/index.html


Still not complete, but better than the originals.

Dale

Re: Expressive Case Statements (was: Software landmines)

[Al Christians]

There is a commercial product that addresses this problem: Logic Gem.
I tried it about 10 years ago and found its user interface seriously
flawed, but besides that, it was ok.  It was a spreadsheet-like 
decision table builder that would generate code (Fortran, C, Pascal,
xBase, Cobol, Ada--NOT! ) and documentation.  It could compress a
decision table down to a simpler form when some inputs sometimes
didn't matter, and it could also expand a simplified table out to
a fully-expanded form.

Part of its input was data on the cost of evaluating the conditions
and the expected frequencies  of the various results.  It would use
this to generate code optimized accordingly.  I think that you could
alternatively generate code that was ordered to be more obviously in
agreement with the input data.

The principal problem, of course, is that code generation was one-way
and there was no way to be sure that the current table and the current
code were consistent other than regenerating the code.  I 
suppose that nowadays a two-way generate/reverse engineer tool would
be what most would want.  If the generated and optimized code comes
out too complex for a review or walk through, I don't know if anyone
should trust it or not. 

I just checked a search engine and see that Logic Gem is still 
available:  see www.logic-gem.com.

I speculate that one might implement a decision table in Ada as some 
some complex generic package.  Client code would add the conditions and 
actions into the generic decision table line-by-line.  The decision
table would then naturally want to check its own consistency and 
completeness before evaluating the conditions and performing the 
actions.  Would anybody be happy running code like that?   

Al


Robert I. Eachus wrote:
> 
> 
>   > Concerning decision tables, the EVALUATE statement in COBOL,
>   > and Robert I. Eachus's suggestion for doing them in Ada,
>   > I don't know what the COBOL standard says about EVALUATE,
>   > but there was one point about decision tables which seems
>   > to have been missed:
> 
>   >   - as well as the condition *combinations* being complex,
>   >   - the condition *elements* may be complex, and
>   >   - you don't want to evaluate them if you don't have to...
> 
>   True, but from experience decision tables are not for situations
> where evaluating all the decision variables is potentially harmful.
> There are often cases where you nest decision tables because some
> predicates should only be evaluated in some cases.  Too many don't
> cares should also be taken as an indication that you have merged
> tables that should be separate.
> --
>

Re: Expressive Case Statements (was: Software landmines)

[Al Christians]

This brings up a larger question that is perhaps beyond the scope of
c.l.a., but I would be interested in the thoughts of the experts here
on this subject:  What should go into data and what should go into
the program?  For example, it would generally be theoretically possible
to create a giant relational database where all the possible answers
from a program could be looked up based on all the possible inputs. 
We don't usually do that, but how does one correctly decide what is best
to code as program logic and what is best to code as data?  

A decision table is a way of presenting a representation of information
that is about midway between that that obviously ought to be programmed
and that that clearly ought to be left as data.  Any general rules to 
apply in this analysis?  How does programming language affect these
tradeoffs?

Al   


Richard D Riehle wrote:
> 
>    Absolutely true statement.  The number of combinations is
>    exponential.  When you get beyond three conditions the
>    problem can become unwieldy.  This is the beauty of decision
>    tables.  Ridiculous choices can be identified immediately and
>    discarded.  The COBOL Evaluate statement allows you discard those
>    inappropriate choices in a readable and well-documented syntax.
> 
> >Decision tables became unfashionable; I never understood why.
> 
>   I'm with you.  I once used a language called LOBOC (COBOL spelled
>   backwards) that was based on decision tables.  Unfortunately, one
>   also had to embed Assembler (Autocoder for those of you ancient
>   enough to remember it) in the code.  The decision tables greatly
>   enhanced our ability to reason about complex relationships between
>   choices and to rule out those that were nonsense.  They also forced
>   us to ask questions about the possibility of a certain set of
>   situations ever occurring.  This helped with error management.
>

Re: Expressive Case Statements (was: Software landmines)

[Tom Moran]

> What should go into data and what should go into the program?
Seems to me that's the classic tradeoff between space and speed, the
answer to which varies according to the economics of what's available.

Re: Expressive Case Statements (was: Software landmines)

[Michael F Brenner]

   > how does one correctly decide what is best to code as program logic 
   > and what is best to code as data?

The decision whether to code a particular portion of an algorithm
as code or data within the software can be made using the same four
criteria (i.e. metrics) used to determine whether to code an algorithm 
as software at all (versus reading in data at runtime).

First, there is the total cost of maintenance. This is almost
always made cheaper by using data rather than code, but analysis
may occasionally find code easier to maintain, particularly if
the data is nested more than the code would be.

Second is distributed size of the system. The more parts the system 
has, the more expensive code becomes than data. For example,
consider the Upper Slobbovian Command and Control System which
tracks all civilian and military flights of airplanes, satellites,
friendly missiles (those aimed away from you), and unfriendlies.
Here a large expense is the fact that some things are classified. It is
much cheaper to read in the classified data at runtime and keep the
software unclassified.

Third is to minimize the coupling. Coupling is the weighted sum
of the globality of the references. Global references get a high
weight; intermediate references get a low weight; purely local
references get a low weight.

Fourth is the controversial cohesion metric. While it does not
compete with lifecycle maintenance cost, distributed size of system,
or non-localization of reference, your selected cohesion metric 
will be your judgement of the localization of function, the relationship
between inputs and outputs, the ease of computing the precondition
from the postcondition, and the single-mindedness of the purpose. There
is a method of measuring this objectively by interpreting the 
software as a braid in a particular braid group and using the
cohesion of the braid as the measure of the cohesion of the
software.

Mike Brenner  mikeb@mitre.org