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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,34349f11b6d01b2 X-Google-Attributes: gid103376,public From: "James S. Rogers" Subject: Re: Tools Date: 1996/12/18 Message-ID: <32B8BE29.2577@worldnet.att.net>#1/1 X-Deja-AN: 204860158 references: <5942ok$p9s@mill.gdls.com> <32B6D316.2F1C@velveeta.apdev.cs.mci.com> content-type: text/plain; charset=us-ascii organization: AT&T WorldNet Services mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.02E (Win95; U) Date: 1996-12-18T00:00:00+00:00 List-Id: Robert Dewar wrote: > I don't think this can possibly be true. Dynamic dispatching is semantically > equiavlent to a series of calls protected by conditoinals, and it would seem > that any methodology which could not handle: > > if a then call-b > elsif b then call-c > ... > > is too limited to be useful. Yes, dynamic dispatching is sematically equivalent to a series of calls protected by conditionals, or even a case statement. A set of conditionals or a case statement is easily evaluated on the fly. The required information is directly available for static analysis. Tagged types differ. They require a static analysis tool to build and maintain a dispatch table for all types, keeping in mind scope and visibility rules for each calling point. Given that the current package may be influenced by a child package which is unreferenced in the current package, this appears to be a task which would not be reliably executed by a tool which was less than a full Ada compiler front end. Jim Rogers -------------------------------------------- Team Ada