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: "Dr Richard A. O'Keefe" Subject: Re: Expressive Case Statements (was: Software landmines) Date: 1998/09/02 Message-ID: <35ECDA3F.3372@atlas.otago.ac.nz>#1/1 X-Deja-AN: 387025755 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> Content-Type: text/plain; charset=us-ascii Organization: Department of Computer Science, University of Otago Mime-Version: 1.0 Reply-To: ok@atlas.otago.ac.nz Newsgroups: comp.lang.ada Date: 1998-09-02T00:00:00+00:00 List-Id: 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.