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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!spp1.UUCP!alden%jade From: alden%jade@spp1.UUCP Newsgroups: net.lang.ada Subject: Re: APSE Trends Message-ID: <8606131702.AA01800@jade.SPP.TRW> Date: Wed, 18-Jun-86 00:52:18 EDT Article-I.D.: jade.8606131702.AA01800 Posted: Wed Jun 18 00:52:18 1986 Date-Received: Thu, 19-Jun-86 19:30:18 EDT References: <8606091044.AA06531@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: Ed, Two of the issues that you are wondering about with respect to their importance that I consider important are those dealing with DIANA and the KAPSE. (You have the CAIS listed separate from a KAPSE, I remind you that the CAIS is just one instance of a KAPSE, and happens to be a proposed MIL STD.). The issue of DIANA can be generically placed in the category of the issue of a standard or common internal representation for ada code. Whetherer the representatio is DIANA or some other future standard, I think the issue is a good one becuase it allows for the possibility of developing small, very specfic tools that work from a common database or preparsed code. For the large kinds of systems that Ada development is suposed to address it self to, it would be impossible from an throughput point of view to to have to compile code once to produce code and once for each tool to be used by the developer. It only makes sense that if there are to be a host of tools that need to parse Ada code before they can do their job, that this only be done once. Given the current speeds of compilation, a trend to reduce this overhead is welcome. With respect to the KAPSE. First my credentials (for what they are worth). I am one of the members of the TRW team developing a CAIS prototype under contract to NOSC. The stated value of a KAPSE is that if tools are written to conform to the KAPSE for all so called O.S. dependencies, then when it comes time to rehost the toolset to a new machine, the tools will be transportable with no (or at least minimal) rework. This is because the KAPSE would be ported and absorb all of the work. For large toolsets, the expense of porting an entire tool suite is likely to be more than porting the KAPSE. Remember that you must include the cost of testing each tool when you change its code. Thus added to the cost of tweaking code for each tool, you must add the cost of completely testing the tool. If you are porting just the KAPSE, it it is likely that the complexity of testing is lower because you have only one program to test. One unanswered question that still remains is how costly will it be to report the KAPSE. This of course depends on what functions are in the KAPSE. Experience with UNIX ports (Unix is considered by many as an example of a KAPSE) shows that ports to new machines are extremely cost effective. Why Unix is not viable for an Ada KAPSE is another issue, not to be dealt with here. Not mentioned yet is the cost of developing small new tools. If you have to reinvent the parsing wheel each time you need a tool that has to run through Ada code, it is likely that it will not be cost effective to develop useful small tools - the overhead of such development would be to high. Having this aspect standardized reduces the overhead of maintenance and development because the develpment community only has to learn one set of such routines and not a new set for each toolset that it needs to modify. The underlying theme that ties both of the above issues together (issue of DIANA and issue of a KAPSE) is that of centralization and standardization. Both of these approaches rely on the idea that if you have a standard for internal representations of Ada code that all tools agree on and have a central place to put this with standard interfaces to work with this repository then tools can be integrated in such a way that their sum power is greater than the additive power of the individual tools. This synergy is what I hope will make the whole effort worth while. ... Tony Alden TRW (213) 535-1624 P.S. The above comments apply to my personal and academic views on the subjects discussed and in no way reflect the official views of TRW or any obligations TRW has to fulfilment of its contractural obligations.