From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: Al Christians Subject: Re: Expressive Case Statements (was: Software landmines) Date: 1998/09/04 Message-ID: <35F031E4.4234C135@easystreet.com>#1/1 X-Deja-AN: 387917944 Content-Transfer-Encoding: 7bit References: <902934874.2099.0.nnrp-10.c246a717@news.demon.co.uk> <6r1glm$bvh$1@nnrp1.dejanews.com> <6r9f8h$jtm$1@nnrp1.dejanews.com> <6renh8$ga7$1@nnrp1.dejanews.com> <6rf59b$2ud$1@nnrp1.dejanews.com> <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <35f51e53.48044143@ <904556531.666222@miso.it.uq.edu.au> <35EAEC47.164424A7@s054.aone.net.au> <6sgn8l$7aq$1@nnrp1.dejanews.com> <6sh487$lnq$1@nnrp1.dejanews.com> <6shit4$eaj@dfw-ixnews5.ix.netcom.com> <35ECDA3F.3372@atlas.otago.ac.nz> Content-Type: text/plain; charset=us-ascii X-Trace: news14.ispnews.com 904933508 206.103.35.201 (Fri, 04 Sep 1998 14:25:08 EDT) Organization: Trillium Resources Corporation MIME-Version: 1.0 Reply-To: achrist@easystreet.com NNTP-Posting-Date: Fri, 04 Sep 1998 14:25:08 EDT Newsgroups: comp.lang.ada Date: 1998-09-04T00:00:00+00:00 List-Id: 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. > -- >