From cooper@longshot.ds.boeing.com Thu Oct 12 15:29:27 1995 Return-Path: Date: Thu, 12 Oct 1995 12:24:39 -0700 From: cooper@longshot.ds.boeing.com (Dan Cooper) To: ASIS-Officers@sw-eng.falls-church.va.us Subject: providing source code pointers in ASIS Content-Length: 2140 X-Lines: 46 Status: RO FYI: Here's another vote on the subject. The author sent the message directly to me and Serge, so I thought I'd forward it. The "project with Rational" that he refers to (TSDT) was prototyped in another division of Boeing, and is now being commercialized by Rational as an ASIS-based tool. (Our web page should mention this, but I don't know Rational's name for it or other details.) ----- Begin Included Message ----- Date: Thu, 12 Oct 95 08:37:24 PDT From: jmk8792@raven.ca.boeing.com (John M. Kinsley) To: Serge.Rybin@lglsun.epfl.ch, cooper@atc.boeing.com Subject: providing source code pointers in ASIS Rainer writes: > I have another item which was addressed at the workshop in > Frankfurt. Some of the members of the workshop including Robert Dewar > pointed out the importance of having source code pointers and > source comments available. How could a pretty printer (identified as a > usual ASIS application) be implemented without that information? > Reverse engineering tools on top of ASIS could profit of available > comments, too. How will the ASIS working group handle this item? Will > ASIS 2.0 classify providing source code pointers and comments as > a) mandatory b) optional c) not at all? I sent mail to Serge about our project with Rational. I feel that it would be a mistake not to include the source code pointers as a mandatory feature within ASIS. We require both line and column number to support our efforts. Although a Pretty Printer is considered much of a tool, there are other applications that may pretty print the code to a window and display test and coverage information interactively about the source code. ------------------------------------------------------------------- John M. Kinsley phone (206) 237-5277 Principal Scientist fax (206) 237-5444 Avionics / Flight Systems email jkinsley@boeing.com Test Specification and Determination Tool (TSDT) Project Boeing Commercial Airplane Group P.O. Box 3707, Mail Stop 6H-TW Seattle, WA 98124-2207 ------------------------------------------------------------------- From JLONJERS@eag.unisysgsg.com Thu Oct 12 18:04:55 1995 Return-Path: From: "Lonjers, James @EAG" To: dewar , JLONJERS , Koschke , "Serge.Rybin" Cc: asis , asplund , barbey , bbug , dewar , dirk , johen_hayek , olavip , rybin , strohmeier , tld_euro , zueff Subject: Re: ASIS Workshop Minutes (Oct 4, 1995, Frankfurt, , 'Ada in Europe 95') Date: Thu, 12 Oct 95 16:35:00 CST Encoding: 15 TEXT Content-Length: 635 X-Lines: 15 Status: RO I am glad you agree with the approach. Having been in standards activities for the past seven years, I have seen optional features be the method of choice for gaining standardization, and yet the standard is unsuccessful because no one can buy a useful one. I also understand the issues with respect to gnat. Having ASIS available on gnat, even without an important feature, is far better than no ASIS on gnat at all. Clearly we also agree on what success is: real applications using a product built to the standard. In this regard, I believe that ASIS (the current version) is successful. Thanks for the feedback. Jim From dewar@nile.gnat.com Thu Oct 12 19:21:53 1995 Return-Path: Date: Thu, 12 Oct 95 18:59:26 -0400 From: dewar@nile.gnat.com (Robert Dewar) To: JLONJERS@eag.unisysgsg.com, Koschke@informatik.uni-stuttgart.de, Serge.Rybin@lglsun.epfl.ch Subject: Re: ASIS Workshop Minutes (Oct 4, 1995, Frankfurt, , 'Ada in Europe 95') Cc: asis@sw-eng.falls-church.va.us, asplund@docs.uu.se, barbey@lglsun.epfl.ch, bbug@avlo.tunie.ac.at, dewar@gnat.com, dirk@offis.be, johen_hayek@acm.org, olavip@cs.fut.fi, rybin@lglsun.epfl.ch, strohmeier@di.epfl.ch, tld_euro@cerf.net, zueff@such.srcc.msu.su Content-Length: 358 X-Lines: 7 Status: RO "Having ASIS available on GNAT, even without an important feature, is far better than no ASIS on GNAT at all" There is some considerable confusion here. GNAT is not the compiler that has trouble with comments, and we expect to fully implement this feature in GNAT, my comments on difficulty of implementation were with respect to other compilers, not GNAT! From sblake@alsys.com Thu Oct 12 19:52:57 1995 Return-Path: Date: Thu, 12 Oct 1995 16:27:22 -0700 From: sblake@alsys.com (Steve Blake @pulsar) To: JLONJERS@eag.unisysgsg.com, Koschke@informatik.uni-stuttgart.de, Serge.Rybin@lglsun.epfl.ch, dewar@nile.gnat.com Subject: Re: ASIS Workshop Minutes (Oct 4, 1995, Frankfurt, , 'Ada in Europe 95') Cc: asis@sw-eng.falls-church.va.us, asplund@docs.uu.se, barbey@lglsun.epfl.ch, bbug@avlo.tunie.ac.at, dewar@gnat.com, dirk@offis.be, johen_hayek@acm.org, olavip@cs.fut.fi, rybin@lglsun.epfl.ch, strohmeier@di.epfl.ch, tld_euro@cerf.net, zueff@such.srcc.msu.su Content-Length: 382 X-Lines: 9 Status: RO I don't believe any of the current ASIS implementations have any trouble with comments or source "pointers" which I take to mean a file name or some other handle to the source. A draft version of ASIS 2.0 will be publicly available by TRI-Ada in November. Certainly, the ASISWG would welcome comments from vendors letting us know where potential problem areas are. Steve Blake From colket@smtp-gw.spawar.navy.mil Fri Oct 13 14:07:00 1995 Return-Path: Date: Fri, 13 Oct 1995 13:08:54 -0400 From: colket@smtp-gw.spawar.navy.mil (Currie Colket) Subject: Re: ASIS Workshop Minutes (Oct 4, 1995, Frankfurt, , 'Ada in To: asplund@docs.uu.se, dirk@offis.be, koschke@grimm.informatik.uni-stuttgart.de, strohmeier@di.epfl.ch, tld_euro@cerf.net, johen_hayek@acm.org, barbey@lglsun.epfl.ch, dewar@gnat.com, olavip@cs.fut.fi, bbug@avlo.tunie.ac.at, zueff@such.srcc.msu.su, rybin@lglsun.epfl.ch, Serge.Rybin@lglsun.epfl.ch (Serge Rybin), colket@smtp-gw.spawar.navy.mil (Currie Colket) Cc: asis@sw-eng.falls-church.va.us Content-Type: text/plain; charset=US-ASCII Content-Description: cc:Mail note part Content-Length: 9858 X-Lines: 167 Status: RO Sergy, I would like to thank you for conducting the ASIS Workshop. I think you had some very interesting discussions. I was pleased to hear that all the participants agree that ASIS could be a good background for developing the portable and easy-to-integrate Ada toolsets. I think this is one of most important aspects of ASIS and will result in powerful and high quality tools available to the Ada community. I would also like to share some of my thoughts with the list of barriers to ASIS adoption in the ASIS community: > 1. ASIS application areas. > ---------------------- > What kinds of tools could really be built on the 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 enginnering 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 and I will remove them from the list in the ASIS FAQ. So the list now becomes: browsers, call tree tools, code reformators, coding standards compliance tools, correctness verifiers, dependency tree analysis tools, design tools, document generators, metrics tools, quality assessment tools, reverse engineering tools, re-engineering tools, safety and security compliance tools, style checkers, test tools, and translators. These are still very important tool areas for which ASIS can be valuable. If there are other tool areas where ASIS can be valuable, I would appreciate input. > 2. ASIS applications - do they really exist now? > --------------------------------------------- > 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. I have been trying to promote the use of ASIS as part of the system application (vice a tool). I suppose I havn'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. I personally think ASIS can be a valuable technology for many system applications. Particularily where it is useful to decouple system to system interfaces to provide flexibility, reduce cost, and support evolutionary development/acquisition. I 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. I don't understand the last statement as even if ASIS was not useful for system applications, it is still highly valuable for building CASE tools. I think ASIS will be very much alive as long as Ada is healthy. > 3. Is the level of the ASIS interface high enough to make ASIS to be really > ------------------------------------------------------------------------ > easy to use for building Ada tools? > ----------------------------------- > > There exist certain needs for the developing of various general-purpose > and specialized interfaces on the top of ASIS which could provide > the interface of higher level than ASIS does for an Ada tool developer. > (May be, ASIS Secondary Layers are the solution of 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 (ASIS95). 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. I 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/asiswg.html ]. Currently there are no public domain secondary layers for ASIS95. As ASIS95 matures, the availability of public domain secondary layers should increase. > 4. Is ASIS really a vendor-independent interface? > ---------------------------------------------- > > It seems that ASIS contains too many implementation-dependent and > implementation-defined features to make it really possible to build > portable Ada tools on its top. In particular, the supporting of the > comments in the source text of the compilation cnits processed by > ASIS and the normalization of the association lists were discussed > as aspects which could seriously influence the portability > of ASIS-based tools. My goal and that of the 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 commemt. 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, I 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 the problem, I 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, I have been personally 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 > free-ware release of the implementation as soon as possible. We are also very excited about your work. We are interested in perhaps having a demonstration of your ASIS implementation at Tri-Ada and perhaps distributing your implementation at Tri-Ada and on the ASIS Home Page. Is this possible? > Another aspect which could make a good impact on the progress of ASIS would be > the development of the set of the free-ware (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. I fully anticipate ASIS95 artifacts will appear once an ASIS95 specification is available. The first public releaseble draft of the ASIS95 interface is planned for Tri-Ada95 in early November. Thank you again for conducting the ASIS Workshop and for your work with the ASIS95 implementation to the GNAT Ada95 compiler. v/r Currie Colket Chair ASISWG/ASISRG colket@smtp-gw.spawar.navy.mil +1 (703) 602-1483 From colket@smtp-gw.spawar.navy.mil Fri Oct 13 15:44:04 1995 Return-Path: Date: Fri, 13 Oct 1995 15:06:21 -0400 From: colket@smtp-gw.spawar.navy.mil (Currie Colket) Subject: Re[2]: ASIS Workshop Minutes (Oct 4, 1995, Frankfurt, , 'Ada To: JLONJERS@eag.unisysgsg.com, Koschke@informatik.uni-stuttgart.de, Serge.Rybin@lglsun.epfl.ch, dewar@nile.gnat.com, sblake@alsys.com (Steve Blake @pulsar) Cc: asis@sw-eng.falls-church.va.us, asplund@docs.uu.se, barbey@lglsun.epfl.ch, bbug@avlo.tunie.ac.at, dewar@gnat.com, dirk@offis.be, johen_hayek@acm.org, olavip@cs.fut.fi, rybin@lglsun.epfl.ch, strohmeier@di.epfl.ch, tld_euro@cerf.net, zueff@such.srcc.msu.su Content-Type: text/plain; charset=US-ASCII Content-Description: cc:Mail note part Content-Length: 646 X-Lines: 19 Status: RO All, Judging from the amount of email traffic on comment and source pointers, this looks like a good item for discussion at the next ASISWG/ASISRG meeting. I encourage thought as to the type of ASIS interfaces desired to support these pointers, and encouragement to discuss ideas by email and presence at the meeting, if possible. The person to contact about attending the next ASISWG/ASISRG meeting is Steve Blake. I apologize abloout leaving off the "s" in his email address. His correct email address should be: sblake@alsys.com v/r Currie Colket Chair ASISWG/ASISRG colket@smtp-gw.spawar.navy.mil +1 (703) 602-1483 From cooper@longshot.ds.boeing.com Fri Oct 13 21:00:09 1995 Return-Path: Date: Fri, 13 Oct 1995 17:21:04 -0700 From: cooper@longshot.ds.boeing.com (Dan Cooper) To: colket@smtp-gw.spawar.navy.mil Subject: Re: ASIS Workshop Minutes Cc: asis@sw-eng.falls-church.va.us Content-Length: 2149 X-Lines: 43 Status: RO Currie, > There are a lot of software enginnering 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 and I will remove them from > the list in the ASIS FAQ. So the list now becomes: > > browsers, call tree tools, code reformators, coding standards compliance > tools, correctness verifiers, dependency tree analysis tools, design tools, > document generators, metrics tools, quality assessment tools, reverse > engineering tools, re-engineering tools, safety and security compliance > tools, style checkers, test tools, and translators. For what it's worth, here's the list I usually publicize: * language-sensitive editing and pretty-printing * data flow analysis and usage metrics * invocation (call) trees and cross-reference * dependency trees and impact analysis * test-case generation and coverage analysis * usage counts of language constructs * quality assessment metrics * coding style and standards compliance * safety and security compliance * code browsing and navigation * document generation * reverse engineering and re-engineering * language translation and code restructuring > 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 (ASIS95). A public domain > secondary layer was developed for ASIS83, called the Program View Layer. I hope it's clear that that layer is 1) distinct and *separate* from ASIS, and 2) just one example of *many* possible secondary layers. C. Daniel Cooper ================================================ Adv Computing Technologist | processes | all opinions are | 206-655-3519 | + architectures | strictly my own, | Cooper@Boeing.com | = systems | NOT my employers | From dewar@nile.gnat.com Fri Oct 13 22:05:46 1995 Return-Path: Date: Fri, 13 Oct 95 21:28:28 -0400 From: dewar@nile.gnat.com (Robert Dewar) To: colket@smtp-gw.spawar.navy.mil, cooper@longshot.ds.boeing.com Subject: Re: ASIS Workshop Minutes Cc: asis@sw-eng.falls-church.va.us Content-Length: 1013 X-Lines: 22 Status: RO * language-sensitive editing and pretty-printing * data flow analysis and usage metrics * invocation (call) trees and cross-reference * dependency trees and impact analysis * test-case generation and coverage analysis * usage counts of language constructs * quality assessment metrics * coding style and standards compliance * safety and security compliance * code browsing and navigation * document generation * reverse engineering and re-engineering * language translation and code restructuring OK, but it is interesting to see how many of the above depend on having source positions and/or comment informationl, both of which are optional in the current ASIS spec! Of the above 13, I estimate that more than half are out of the question without source position and comment information, and several of the remainder are badly damaged if their output cannot be easily keyed back to the original sources. From Serge.Rybin@lglsun.epfl.ch Mon Oct 16 07:46:12 1995 Return-Path: Date: Mon, 16 Oct 95 12:17:40 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: asplund@docs.uu.se, dirk@offis.be, koschke@grimm.informatik.uni-stuttgart.de, strohmeier@di.epfl.ch, tld_euro@cerf.net, johen_hayek@acm.org, barbey@lglsun.epfl.ch, dewar@gnat.com, olavip@cs.fut.fi, bbug@avlo.tunie.ac.at, zueff@such.srcc.msu.su, rybin@lglsun.epfl.ch, Serge.Rybin@lglsun.epfl.ch, colket@smtp-gw.spawar.navy.mil Subject: Re: ASIS Workshop Minutes (Oct 4, 1995, Frankfurt, , 'Ada in Cc: asis@sw-eng.falls-church.va.us Content-Length: 9111 X-Lines: 161 Status: RO Currie, > > I would also like to share some of my thoughts with the list of barriers to ASIS > adoption in the ASIS community: > > > > 1. ASIS application areas. > > ---------------------- > > There are a lot of software enginnering 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 and I will remove them from > the list in the ASIS FAQ. So the list now becomes: > > browsers, call tree tools, code reformators, coding standards compliance > tools, correctness verifiers, dependency tree analysis tools, design tools, > document generators, metrics tools, quality assessment tools, reverse > engineering tools, re-engineering tools, safety and security compliance > tools, style checkers, test tools, and translators. > > These are still very important tool areas for which ASIS can be valuable. If > there are other tool areas where ASIS can be valuable, I would appreciate input. The only comment I have is that during the workshop in Frankfurt many participants insisted on adding "static" to "metrics tools", and "correctness verifiers" when we went through the list of the potential ASIS applications. > > > 2. ASIS applications - do they really exist now? > > --------------------------------------------- > > I have been trying to promote the use of ASIS as part of the system application > (vice a tool). I suppose I havn'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. I personally think ASIS can be a > valuable technology for many system applications. Particularily where it is > useful to decouple system to system interfaces to provide flexibility, reduce > cost, and support evolutionary development/acquisition. I 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. The fame of ASIS *OUTSIDE* the ASISWG is the problem. Too few people known even about the general idea of ASIS. And as for the System 1 example from ASIS FAQs, I am afraid, that as it stands now, it does not work with the people who have not got the eetailed knowlege about ASIS. When an ASIS newcomwr sees some technical explanations concerning ASIS "ID", he could probably stop reading at all. Shame on me, but having been working in ASIS context for more that a year, I am able to guess only the general idea of the example (even with the help of the slides you sent me). May be, taking into account that ASIS FAQs (as FAQs) should be catered mostly for people who knows nothing or almost nothing about ASIS, it could be useful to rewrite the section "How might an Application use ASIS" and to replace the System 1 example (which is perfect on its own!) for a series of more "traditional" examples. (Unfortunately, I myself have no concrete idea, but I think that the reply of Michael Grundhofer to my "Minutes" may give a good starting point. > > > 3. Is the level of the ASIS interface high enough to make ASIS to be really > > ------------------------------------------------------------------------ > > easy to use for building Ada tools? > > ----------------------------------- > > > 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 (ASIS95). 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. > I 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/asiswg.html ]. I would be very glad to take part in the meeting, but I am afraid that the budget of our progect does not allow me to come. I am awfully sorry :((((( > > My goal and that of the 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 commemt. 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. I am afraid there is a misunderstanding concerning comments. On the workshop, the main point of the discussion around comments was that it would be nice (or necessary, as some of the participants insisted) to have the ability to get comments through the ASIS interfaces (as well as precise Element coordinates in the source text) as mandatory, but not as implementation-defined ASIS feature. > As to the second case addressing the > normalization of the association lists, I 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 the > problem, I 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. As for the particular ASIS implementation dependencies, I am not ready to write up the concrete problems for the detailed technical discussion now. But I have a general question: should all the information about implementation dependencies be available through the Asis.Environment queries? And if the ansver is "yes", what about the permission for ASIS implementation to normalize the multi-name declarations into an equivalent series of corresponding single-name declarations? > > 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 > > free-ware release of the implementation as soon as possible. > > We are also very excited about your work. We are interested in perhaps having a > demonstration of your ASIS implementation at Tri-Ada and perhaps distributing > your implementation at Tri-Ada and on the ASIS Home Page. Is this possible? What we have now is a working partial prototype. Its main limitation is that it can process only one compilation unit at a time. It contains almost all structural queries from ASIS 2.0.C implemented. The systematic testing and debugging have not been performed so far. We hap plans to make it available in November 1995, but now (in full accordance with Murphy laws :( :) we have changed the date for the end of 1995. Now our prototype is ready for demonstration, but it requies some more work to be done to make it ready for distribution. But, as I said above, the main problem for me is to find money to come to TRI-Ada. Sergey Rybin, ASIS-for-GNAT Project, currently in Swiss Fed Inst of Technology, Lausanne.