Code generation from truth table.

artist has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,
I like to generate the efficient code from the truth table and would like to know if we have any tools available.

For example, sulfericacid like to design a system to add/remove email addresses via CGI form based upon if users have provided proper fields and email address exists or not in the database. While talking in CB, I created the truth table.

name email add emailexist step:					
T    T     T   T	  warn 1. email exists in database
T    T	   T   F	  action 1: add email in database
T    T	   F   T	  action 2: remove email from database
T    T	   F   F	  warn 2. email doesn't exist in database
T    F	   -   -	  warn 3. email empty
F    T	   -   -	  warn 4. name empty
F    F	   -   -	  warn 5. name and email empty

Notes:

Name: 'T' If user has provided name
Email: 'T' If user has provided email
Add: 'T' if radio button for 'add' is checked. (other option is to remove
Emailexist: 'T' if email exists in the database
- : It's not relavent.

Sample code

if(form){
    if(name){
        if(email){
            if(option=add){
                if(stored){
                    warn1:email exists
                    }
                else{
                    action:add email
                }
            }
            else(option=remove){
                if(stored){
                    action:remove email
                    }
                else{
                    warn2: email doesn't exist
                }
            }
        }
        else{
            warn3: email empty
        }
    }else{
         if(email){
        warn4: name empty
         }
         else{
            warn5: name and email empty
         }
    }
    
}
[download]

According to me, the truth table provides the business logic. While programming we convert the business logic in the code. If we can represent the business logic in truth table and have the code-generator, it would be very helpful. With few fields, it could be common sense, with more fields it is usually a long mental/paper exercise to come up with good code. Our focus will be rightly shifted towards truth table generation in these type of case.

artist

Comment on Code generation from truth table. Download Code

Replies are listed 'Best First'.
Re: Code generation from truth table. by dragonchild (Archbishop) on Apr 09, 2003 at 17:04 UTC
Instead of writing it as a truth table, write it as a state machine. I would translate that as follows: Do I have name? Y -> 2, N -> 10 Do I have email? Y -> 3, N -> 13 Do I have add? Y -> 4, N -> 7 Does email exist? Y -> 5, N -> 6 Warn that email exists Add email to DB Does email exist? Y -> 8, N -> 9 Remove email Warn that email doesn't exist Do I have email? Y -> 11, N -> 12 Warn that name is empty Warn that name and email are empty Warn that email is empty Now, you want to know how to programatically do this from a data structure? Well, there are state machine modules on CPAN. I'm not going to suggest one cause I've never used them. If you don't want to go that route, I would suggest using sub generators and a hash table of paths. As an aside - business logic is generally much more complicated than a truth table can represent. That's why state machines (and their little cousins flowcharts) are much better. They're something both business analysts and developers can understand and analyze for correctness and completeness. ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.	[reply]
Re: Code generation from truth table. by l2kashe (Deacon) on Apr 09, 2003 at 17:26 UTC
I just want to comment on the table itself and code generation. In the table sense you are examining pieces overall to determine what to do, and how, which relates to how things are coded. But the ability to look at the "big picture" for the person defining the table isn't available to the person writing the code. each item needs to be checked, and as the table becomes more complex the lookups follow suit. The way many algorithms tackle this is by weeding out exceptions early, then based on what is left focus on doing something in particular... I think an example might be in order, so lets take your table and transform it to a "coding paradigm"... cause Im lazy, nesting in code tags is easier... ## Original table from business flow perspective.. name email add emailexist step: T T T T warn 1. email exists in database T T T F action 1: add email in database T T F T action 2: remove email from database T T F F warn 2. email doesn't exist in database T F - - warn 3. email empty F T - - warn 4. name empty F F - - warn 5. name and email empt # New table from code perspective.. name email add emailexist step: F F - - action 1: fail not enough input T F - - action 2: fail not enough input(email) F T - - action 3: fail not enough input(name) - - - - can we talk to DB? ( what do we do if we can +t? ) - - - - do we have read/write access to DB? ( what d +o we do if we dont? ) - - T/F - what are we doing? - - T - we are adding - - T T action 4: error email already exists - - T F action 5: add email to database - - F F action 6: fail cant remove what isnt there ( + or is this ok? based on what? should this be fatal? should it collec +t more info? from where if so? ) - - F T action 7: remove email from DB [download] Now you will notice there are far more dashes in the second table.. because by the time we get to those points in the code, the other data points dont matter, because they have been checked and dealt with (sanitize, etc..) So while I think the idea of creating say a template/table of some sort that will produce code is a noble idea, it's one people have wrestled with for a long time. I mean look how simple HTML is, and yet there are relatively few (none in my knowledge, but I'm not that knowledgable so Im acknowledging they may be out there) HTML composers that produce clean sane, trim HTML which doesnt even have a loop structure... what about localization of data? what about configuration changes based on multiple backends or multiple frontends? what about multiple workhorses (i.e distributed computing, or thereabouts) for single/multiple front/backends? what about code speed optimizations? what about creating sub functions to deal with similar occurances of say particular checks used by multiple other pieces of code (i.e input sanitation/validation)? From the human perspective it is very easy to look at something and say this goes with that, whereas in code it usually takes some expertise somewhere along the way to give the "appearance" that things are actually logically connected. I mean simply examine OOP. This and that are derivitives of this thing. Look at all the semantics involved with it, we can't even decide how to definitivly define what new() should be (tounge in cheekish)... /* And the Creator, against his better judgement, wrote man.c */	[reply] [d/l]
Re: Re: Code generation from truth table. by mojotoad (Monsignor) on Apr 10, 2003 at 06:55 UTC
Excellent response to data in the "real world". You will no doubt find Why I Hate Nested If-Else blocks interesting, as well as the sub-thread regarding guard clauses. Matt	[reply]