List of participants (I am awfully sorry if I made mistakes when decoding your hand-writting ):
All the participants agree that ASIS could be a good background for developing the portable and easy-to-integrate Ada toolsets, but now there are some number of open problems around ASIS which are or could be barriers for ASIS adoption in the Ada community.
During the Workshop the following ASIS open problems were discussed. After the Workshop, additional follow-up comments were provided (these are shown in italics).
What kinds of tools could really be built on top of ASIS? There are
certain doubts and/or unclearnesses concerning some tools which are
frequently included in potential ASIS application areas. In
particular, debuggers, automated code monitors and timing
estimators were indicated during the Workshop as the tools which
could hardly be built on the top of ASIS.
There are a lot of software engineering tools where ASIS would have
little value. Real-time debuggers, automated code monitors and timing
estimators are three of these. They were included on the list because
people had discussed the use of ASIS to support tools in these domains
and in some cases, ASIS was used. These are not main-stream
application areas for ASIS, thus the list in the ASIS FAQ now becomes:
code restructuring tools, code browsing and navigation tools,
coding style and standards compliance tools, cross-reference
tools, data flow analysis tools, dependency tree analysis tools,
design tools, document generation tools, invocation (call) tree
analysis tools, language-sensitive editing and pretty-printing
tools, language translation tools, quality assessment tools,
reverse engineering tools, re-engineering tools, safety and
security compliance tools, static correctness verifiers, tasking
analysis tools, test-case generation and coverage analysis tools,
and usage, quality, and complexity metrics tools.
These are still very important tool areas for which ASIS can be
valuable. If there are other tool areas where ASIS can be valuable,
ASISWG/ASISRG would appreciate input.
No one from the workshop participants could say that he knew
something about any existing ASIS application or about somebody who
was working with some particular ASIS application (except the
example from ASIS FAQs). This is why many people may consider that
ASIS is simply one more "dead" Ada artifact.
We have been trying to promote the use of ASIS as part of the system
application (vice a tool). We haven't been very successful. So far,
the use of ASIS for system applications has been extremely limited with
only one highly successful (and publicized) use. IBM (now Loral) did
use ASIS very successfully to delog data from a satelite called System
1. It resulted in reduced cost with significantly enhanced future
capabilities. We think ASIS can be a valuable technology for many
other system applications. Particularily where it is useful to
decouple system-to-system interfaces to provide flexibility, reduce
cost, and support evolutionary development/acquisition. We hope the
use of ASIS for system applications will become more widespread as the
use of Ada becomes more widespread. In a sense, the use of ASIS for
applications is dependent on the use of Ada for system applications and
innovative thinking on using the ASIS technology to support the
application's requirements.
We don't understand the last statement as even if ASIS were not useful
for system applications, it is still highly valuable for building CASE
tools. We think ASIS will be very much alive as long as Ada is
healthy.
There exist certain needs for the developing of various
general-purpose and specialized interfaces on top of ASIS which
could provide a higher level interface than ASIS does for an Ada
tool developer. (Maybe, ASIS Secondary Layers [now called toolkits]
are the solution to the problem, but there is too little information
about them.)
ASIS is at a relatively low level. It was intended to provide the
necessary primitive operations to extract syntactic and semantic
information from the Ada Program Library (ASIS83) and the Ada
environment (ASIS 95). A public domain secondary layers was developed
for ASIS83, called the Program View Layer. It provides higher level
abstractions/views to obtain information associated with declarative
regions (i.e., symbol scopes), Ada entities (i.e., types, objects,
subprograms), Ada entities referenced within an Ada unit, and transfers
of control among statements of an Ada program unit. Additional
secondary layers/abstractions could be valuable. The ASISWG/ASISRG have
viewed that the primary, low-level interfaces are appropriate for the
ASIS standard as these are the necessary interfaces. Higher level
abstrations can be built in terms of these interfaces just like MOTIF
is built on the lower Xlib and Xt intrinsics. Generally interfaces
that are identified for secondary layers are excluded from the ASIS
specification unless performance could be significantly enhanced by
placing the interface in the ASIS specification. If one could make a
strong case for including a specific higher level secondary interface
which would convince the ASISWG/ASISRG, then it would be included as
part of the ASIS specification. We encourage you to come to the next
meeting and get involved [2-4 November 1995 in San Diego; contact Steve
Blake at blake@alsys.com for details or check out the ASIS Home Page on
http://www.acm.org/sigada/wg/asiswg].
Currently there are no public domain secondary layers for ASIS 95. As
ASIS 95 matures, the availability of public domain secondary layers
should increase.
It seems that ASIS contains too many implementation-dependent and
implementation-defined features to make it really possible to build
portable Ada tools on it. In particular, the supporting of the
comments in the source text of the compilation units processed by
ASIS and the normalization of the association lists were discussed
as aspects which could seriously influence the portability of
ASIS-based tools.
A goal of ASISWG/ASISRG is to make ASIS as implementation/vendor
independent as possible. To the most part, such implementation and
vendor dependencies have been eliminated from the the interface. The
ASIS Workshop cites two cases where there are problems. The first case
cites the processing of comments in the source text. ASIS simply
provides the means to extract the text of a comment. The use of
commentary is not under control of ASIS nor should it be. Vendors
supporting PDL use different notations and different placement of
comments (i.e., before or after commented entity). It is outside the
scope of ASISWG/ASISRG to standardize how commentary should be used to
support PDL tools. SIGAda or WG9 should be broached for the creation
of a separate group if there is enough interest in this area. As to the
second case addressing the normalization of the association lists, We
have talked to several people about potential implementation dependent
problems with association lists yet we are still unclear as to what the
problem is. If you could provide a write up of this problem, we will
include it on the agenda for discussion at the next ASISWG/ASISRG
meeting. Also if there are any other implementation/vendor dependent
issues, this is a good time to bring them our attention. Although
ASIS-based tools are not expected to be 100% portable from one Ada
environment to another, we have been pleased with the high degree of
implementation independence provided by ASIS. It is a goal of
ASISWG/ASISRG to provide an interface that minimizes the cost of
porting a tool from one Ada environment to another. We will seriously
address any thoughts in this area. Again you are encouraged to attend
the ASISWG/ASISRG meeting to address your concerns in this area.
ASIS 2.X implementation for the GNAT compiler could give a good impact
for ASIS activities, so it is very important to obtain the first
workable freeware release of the implementation as soon as possible.
We are also very excited about your work. We are interested in
distributing your GNAT ASIS implementation at Tri-Ada and on the ASIS
Home Page. Is this possible? [Sergey has replied in the affirmative;
it is scheduled to be available by the end of 1995.]
Another aspect which could make a good impact on the progress of ASIS
would be the development of the set of the freeware (or low-cost) ASIS
applications for some typical problems. These applications could be
used both for practical purposes and for the demonstration of the
concepts and abilities of ASIS.
The ASIS Home Page already has the ASIS83 specification, secondary
interfaces, tutorials (with examples), a conformance suite, and
pointers to a complete ASIS application. All this is currently
available in the public-domain. Members of the Ada ASIS community are
encouraged to provide artifacts which can be made available to the
public. We fully anticipate ASIS 95 artifacts will appear once an
ASIS 95 specification is available. The first public releaseble draft
of the ASIS 95 interface is planned for Tri-Ada'95 in early November.
Last update 24 October 1995. Questions, comments to Clyde Roby (CRoby@IDA.Org)