From jj@ddci.dk Thu Jul 11 11:02:20 1996 Return-Path: Sender: jj@ddci.dk Date: Thu, 11 Jul 1996 16:29:43 +0200 From: Jesper Joergensen To: roby@ida.org Cc: jj@ddci.dk, sblake@alsys.com Subject: Id's and ID_Segment's Content-Type: text/plain; charset=us-ascii Content-Length: 24664 X-Lines: 549 Status: OR Hi Clyde, When I started reading the ASIS spec, I had difficulties seeing what ID_Segments ahere intended to be used for. I asked Steve Blake and Gary Barnes. From the answers I got, it seems that ID_Segments as well as Ids are superfluous when dealing with Ada 95. There, I propose to remove them from ASIS-95. Steve Blake suggested that I submitted this to you as an issue. That is hereby done. Below is the email communi- cation, that I have had with Gary Barnes on the subject. /Jesper jj -> geb, 1996-06-27 Sorry for disturbing you with this. I have asked Steve Blake about the semantics and intentions of Id_Segments in ASIS. It seems he would rather have you answer. Therefore I include my email communication with him and hope you will find the time to clarify things. There are two emails both from Steve to me but with my original emails quoted in the top, so everything should be there. ------------------------- Steve -> Jesper ------- >I'm the guy that went to Ada Europe and gave the talk on ASIS, that you >were originally supposed to give. I also went to the ASISWG meeting. > >As you may know, we have just started implementing ASIS for our Ada 95 >compilers. > >After having read the ASIS 2.0.G I have a question that noone could >answer at the ASISWG meeting, so they suggested that I ask you: what >are ID_Segments and what are they intended for. I can't find any >explanation on them in the specification itself (this is, of course, >not the same as it isn't there). > >/Jesper, DDC-I Jesper, sorry for the delay in my reply. You are right, There is very little explanation for them. They are intended to be a means of "flattening" ASIS.Ids which might contain access types in their vendor representation. Writing Ids with such access types to a file would obviously have no meaningful value if later read and applied to another invocation of ASIS. So this is provided as an alternative to users to guarantee the persistentcy of ids. Depending on you id implementation, you may need to create an Id_Segment bu slurping in all the id information and ensuring it to be persistent by adding additional information. The Id_Segment itself might just be a series of integers enough to hold the info. It can be written and read, and then converted back to an Id. In the TeleSoft ASIS implementation, we did not have any access types in our ids, so we just used a constrained array of integers large enough to hold the id value, and did unchecked conversions back and forth. The concept is similar to that of Asis.Portable_Transfer. Let me know if this makes sense or not. Another person to ask would be Gary Barnes at Rational. He wrote this part of ASIS. Steve Blake ------------------------ also Steve -> Jesper -------- >But as I read the requirements in Asis.Ids, in particular that an Id can be >written to a file, later read in again and converted to an Element, it >would not be a "legal" implementation to write out access type values in an >Id. I don't see that Asis.Ids allows that this is only possible in the same >invocation of Asis, but perhaps this was in fact the intention? > >/Jesper Yes, I got the same impression reading this again the other day. I believe you guessed the intention. I can't find any archive discussion of the subject. Have you tried Gary Barnes (geb@rational.com)? Steve Thanks, Jesper ===================== geb -> jj,sblake 1996-06-27 I realize that you know most of this, but bear with me for the purposes of a coherent exposition. ASIS is a facility for walking a series of tree (circular DAG if you prefer) data structures. Each structure represents some Ada unit that makes up some part of an Ada program, programs, "library", or in Ada 95, "environment". As an ASIS application walks overs the trees, at any given moment it has in its possession an "Element" of that tree. That Element is how the application communicates with ASIS and it is how the application tells ASIS "Here, this is where I am asking the question. What is the of this position in the tree of this unit?" Certain applications exist that have a need (or simply the desire) to record an Element (a library, a tree, and a tree position) for later use by some other application or even by another future instance of the same application. An example might be a theorm prover that wants to be able to work incrementally. It would take snapshots of its progress by taking note of "where" it was in its analysis and it would be able to restart the analysis from that place. Thus giving it flexibility in the face of hardware failures and whatnot. The basic need is to take an Element, or some sort of "reference" to an Element, and be able to write that Element/reference to some sort of I/O or storage device and to be able to read such an Element or reference after it has been written. Elements are very dynamic entities. In particular, they will of necessity always contain access values. (Or, they may contain the functional equivalent of access values. For example, it is possible to simulate access values by storing array indexes instead of access values.) ASIS.Compilation_Units (or ASIS.Units in ASIS'95-speak) are guaranteed to contain access values (or simultated access values). Why? Because An ASIS.Library is opened, and ASIS.Compilation_Unit values are obtained from those libraries and it is possible to get back to the Library from the Compilation_Unit value. That implies some sort of circular reference between the two. (Note: It is conceivable that an library could be implemented as some sort of "pool" of unit values, perhaps even a slice of some huge array of all possible unit values, and then a unit value is nothing more than an index into this array. And then to determine the library for a unit it is then simply necessary to figure out from a table what library corresponds to some unit array index. However, such an implementation is hightly unlikely simply from a storage utilization standpoing. (Huge arrays being allocated and reallocated and reallocated as new libraris are opened.) So it is possible to imagine an implementation of Units that did not actually contain circular references back to Libraries, but the chances of anyone being able or willing to actually use such an implementation is slight. ) Continuing on, ASIS.Elements are guaranteed to contain access values (or simulated access values)? Why? For the same reason. Elements are ultimately obtained by first obtaining a Unit. The Unit is then queried to get the root Declaration Element of the unit. All other Elements of that Unit are then obtained by starting at that root and traversing the Unit tree. And, is is possible to ask the question "What Unit are you from?" for all Element values. This implies some sort of circular reference between the two. (Note: Like with Units, it is possible to imagine implementations where the circularity is implicit in the location of the Element data rather than explicit within the Element itself. However, such implementations are very unlikely. Also, it doesn't matter that such implementations are merely unlikely. All that matters is that known existing Ada librarian implementations don't and won't use such implicit circularities. I don't mean ASIS implementation, I'm talking about the existing Ada librarian facilities of various vendors. The underlying librarian data structures upon which ASIS is merely implemented, and which ASIS data structures directly reference, are implemented in this fashion and ASIS data structures in fact end up with (real or simulated) access values pointing to these librarian data structures. ) The purpose of saying all of that about circular data references is simply to say that ASIS data structures (Library, Compilation_Unit, and Element) are not suitable for direct use with any ordinary I/O facility such as Text_Io, Sequential_Io, Direct_Io, or anything else that would normally be found in the average operating system. The reason they are not suitable for such I/O is that they contain dynamic access values that will not be valid when read by some other application or by some other instance of the same application. Because of this, it was necessary to design some facility that would allow applications to read and write some sort of "reference" to ASIS.Element values. The abstraction that resulted is the ASIS.Id data type. That is why ASIS.Ids exist. In order to understand why ASIS.Id_Segments exist we must first discuss other parts of ASIS. ASIS requires an implementation to provide access to various Elements that may not have any direct physical existence in the underlying Ada librarian. These things are documented in the various documents that I authored while I was helping with ASIS v1.1.1. Examples of such things include, but are not limited to: - Elements of declarations of derived subprograms. An Ada compiler does not need to actually build declarations for these. There are techniques for correctly performing Ada compilation by sharing the declarations of the original subprogram. However, ASIS requires that there appear to be such derived declarations and it requires that they not be Asis.Elements.Is_Equal to the original declarations. So some ASIS implementations will have to simulate the existence of these compiler-unnecessary declarations. - Elements of declarations of implicit builtin operators and attribute functions are likewise often completely unnecessary from the viewpoint of a compiler. However such things are deemed necessary from the viewpoint of an ASIS application. So once again there exist things which will have to be simulated by some ASIS implementations. - Elements of generic instances are particularly troublesome. Generic instance specifications are very likely to exist in all librarians. It is extremely difficult, perhaps impossible, to correctly compile Ada programs without performing the equivalent of macro expanding a generic specification at the site of each and every generic instantiation. From an ASIS perspective, difficulties occur when a compiler or librarian decides to share the expanded instance specification between two different instantiations. At that point the ASIS.Element values from the two separate instance must test as no ASIS.Elements.Is_Equal and yet the underlying librarian data structure is identical. So this is yet another simulation. Also from an ASIS perspective, difficulties occur with "shared code" generics. These are generics which are compiled into executable code exactly once. And each and every instantiation of that generic invokes exactly the same code. Such code is capable of correctly executing regardless of the generic formal types or procedures. In cases like this, there is no macro expanded generic body for any of the generic instances. And yet, ASIS requires (quite reasonably so in my opinion) that every instance have not only an implicit specification but also and implict body and that both of these be fully traversable. (Of course, to traverse them, the body of the generic as well as the generic instance must have been compiled.) This implies that there is likely to be (at least in some ASIS implementations) a great deal of generic instance simulation going on. And, since generic's can instantiate other generics, such simulation is recursive. A simulating implementation will have to be able to simulated a simulted instance inside another simulated instance inside another simulated instance inside ... The fact that some Elements need to be simulated is not necessarily a problem. Each of the places in ASIS where an ASIS implementation *might* be forced to provide a simulation, the ASISWG was very very very careful. In each of the situations, except for generic instances, the degree of potential simulation was very very very restricted. In fact, except for generic instances, each simulation could be easily and correctly performed a tiny finite-state-machine. This allows each Element value, except for generic instances, whether simulated or not, to be represented by a single non-heap-based variant record. This allowed three vital things. First, it meant that ASIS.Element values could be simple variant record types. Second, because they could be simple variant record types, it was possible for Ada functions to return such values and to return unconstrained arrays of such values. This was vitally important because it meant that Element values did not need to be heap based (they did not need to be implemented as access values). Third, because they did not need to be implemented as access values by any implementation, there did not need to be ASIS facilities for deallocating those values. And that meant that use of the ASIS facilities would be *tremendously* easier. There were no storage leaks to worry about. None whatsoever. A major source of bugs in any program was completely eliminated. However, generic instance simulations are a problem. As I mentioned above, a simulated instance may need to "contain" other simulated instances which contain other simulated instances...to an arbitrary level. If we ignore nested generic instances, simulating an expanded generic instance, eithe specification or body, is not terribly difficult. It can be tedious but it is not difficult. This is exactly what all of the Rational ASIS implementations do. The simulation simply has a) a pointer into the generic template specification or body whose expansion is being simulated, b) a pointer to the semantic context where the generic was instantiated, and c) a pointer to the semantic information for the arguements of the instance. Except for the very few ASIS semantic interfaces (such as Expression_Type or Name_Definition) the simulation is trivial. And even the semantic portions are more tedious than complicated. However, when we consider simulating nested generic instances, we suddenly realize that we need the data for a, b, and c that we had before, but we also neee d) a pointer to the outer generic instance context. And we even need e) a pointer to the context outside of that, and f) a pointer to the context outside of that, and g) .... We end up needing, in essense, a linked list of nested generic instance contexts. This also means that either a) an ASIS.Element is no longer of bounded length and so cannot be an element of an array (and the entire ASIS interface design falls apart), or b) certain ASIS.Element values must now contain access values (or simulated equivalents) in order to be able to reference variably sized and variably nested simulated generic instance contexts. This means that the data for an ASIS.Element is (sometimes) no longer fully contained by the ASIS.Element data value itself, and that the data that represents an ASIS.Element value is (sometimes) of very great and variable size. And given that, we get back to the concept of ASIS.Id. An ASIS.Id is a value that can be used by the ASIS implementation to reconstruct the ASIS.Element value that was used to create the ASIS.Id in the first place. Since the ASIS.Element value is not guaranteed to be of a single fixed maximum size (or since that maximum size is potentially very very very large, thousands of bytes per Element) it is no longer possible to guarantee (or at least, it is not longer desirable) that every ASIS.Id value is the same maximum size. Because ASIS.Elements vary in actual size, ASIS.Ids vary in actual size. And yet, the ASIS interface still wants to return ASIS.Id values and even perhaps arrays of ASIS.Id values. We wanted code to look like this: declare A : Asis.Element := ASIS.Some_Interface (...); B : Asis.Element; C : Asis.Id := ASIS.Some_Other_Interface (...); D : Asis.Id; begin while ... loop B := Asis.Some_Third_Interface (A); if ... then D := C; else D := ASIS.Some_Fourth_Interface (...); end if; ...code using A, B, C, and D... end loop; end; because such code is vastly easier to write and maintain than code like this: declare A : constant Asis.Element := ASIS.Some_Interface (...); C : constant Asis.Id := ASIS.Some_Other_Interface (...); procedure Confusing (B : Asis.Element; D : Asis.Id) is begin ...code using A, B, C, and D... end Confusing; begin while ... loop declare B : constant Asis.Element := Asis.Some_Third_Interface (A); begin if ... then Confusing (B, C); else Confusing (B, ASIS.Some_Fourth_Interface (...)); end if; end; end loop; end; Ada does not make it convenient to handle and pass around variable sized data values that are not fully contained by a variant record. ASIS provides a facility for reading and writing these variable sized ASIS.Id values. Those facilities are sufficient for any application that merely wants to be able to store ASIS.Id values in some file that contains nothing but ASIS.Id values. And, there are a number of applications that are fully satisfied by those facilities. However, there exist applications that want to store ASIS.Id values (or their equivalent) in files that contain other data types as well. Ada 83 does not provide any facilites for files that contain more than one data type (unless you convert each data type to a string or some other "stream" representation and then read/write that other representation). Ada 95 on the other hand provides the I/O stream concept and implicit conversion facilities to/from that I/O stream. So Ada 95 is much simpler. But, the ASIS v1.1.1 design was for Ada 83, so back to that discussion... For applications that wanted either a) the ability to write out ASIS.Id values to files that contain mixed data or b) the ability to create "pure" (not access values) record types of their own, which could then be read/written to/from files, it was necessary to have some form of ASIS.Id that could be used in this fashion. That is where ASIS.Id_Segment and ASIS.Id_Segment_List came in. This gave the application the ability to obtain a "pure" (no access values or simulated access values) data value that represented an ASIS.Element. The application could then read/write that pure value or it could store that value into pure data types of the application's own devising. This was considered to be a crucial facility. And, our customers have made extensive use of this facility. With Ada 95, the ASIS.Id_Segment and ASIS.Id_Segment_List facilities are no longer necessary. They can be replaced with Ada.Stream facilities. The ASIS specification merely needs to require that the ASIS implementation provide ASIS.Id, 'Write, 'Input, and 'Output facilities. The application can then create its own memory-to-memory Ada.Stream derivative type that is then used to "read" or "write" and ASIS.Id values into Ada.Streams.Stream_Element_Array. And in fact, the Asis.Id facilities of ASIS v1.1.1 could be eliminated completely and replaced by ASIS.Element'Write, 'Read, 'Input, 'Output. Those would simulataneously give the ability to read/write complete Element values and the ability to create in-memory pure value equivalents for Element values. The ASIS implementation of the attribute functions would provide the equivalent of the current ASIS facilities. Asis.Element <=> Asis.Id <=> Asis.Id_Segment_List facilities) And that is the history and rationale behind ASIS.Id_Segment and ASIS.Id_Segment_List. Vital for Ada 83, unnecessary for Ada 95. Gary ================================= jj -> geb,sblake 1996-06-28 Gary, Thanks for a very, very thorough explanation on id_segments. Let's see if I understood correctly: 1. Id segments (and lists of them) are not necessary in ASIS for Ada 95, 2. In ASIS for Ada 83 they were actually only necessary for implementations that share code for generics. Implementations that macro expand specifications AND bodies for generic instances don't need them. As I understand, you would propose to get rid of id_segments in ASIS 95. /Jesper =================================== geb -> jj 1996-06-28 > Gary, > > Thanks for a very, very thorough explanation on id_segments. Let's see > if I understood correctly: > > 1. Id segments (and lists of them) are not necessary in ASIS for Ada 95, Correct. > 2. In ASIS for Ada 83 they were actually only necessary for > implementations that share code for generics. Implementations that > macro expand specifications AND bodies for generic instances don't > need them. No. Some compilers never generate (and/or retain) expanded generic bodies. Shared code generics are merely the most likely reason for such a thing. And, it has nothing to do with ASIS implementations. They exist for *applications*, not *implementations*. They were necessary for ASIS-using *applications* that want to do certain varieties of operations portably. Applications that wanted either a) to have binary files containing mixed data types including ASIS.Id values, or b) to have record (or array) types that were "pure" (guarenteed to contain no access values, meaning that they can be read/written to files without worry about invalidating hidden pointer values). Without the Id_Segment{_List} type(s), such portable applications would have been *impossible*. Not hard, not difficult, literally *impossible*. That is why they existed. > As I understand, you would propose to get rid of id_segments in ASIS 95. More than that. I would eliminate the ASIS.Id type as well. All ASIS has to do is the equivalent of specifying that ASIS.Element'Write, 'Read, 'Input, and 'Output exist and that they do what ASIS.Id's did before. That is, they provide a way to create a "reference" to an ASIS.Element value that can be written, and then later read and, by being read, that reference is automatically converted back into an Element value. For the purposes of 'Read and 'Input, which do *not* and *can* not have an ASIS.Library parameter, this would require that ASIS have some sort of "current Library for I/O" concept/interal-state. But it completely eliminates the entire ASIS.Id package and eliminates the need for the application to deal with the concept of ASIS.Id at all. Of course ASIS could have the following, which would probably be better than defining 'Write, 'Read, 'Input, and 'Output because this way the ASIS library does not have to contain state: package Asis.Element_Io is procedure Write (Stream : access Ada.Streams.Root_Stream_Type'Class; Element : in ASIS.Element); procedure Output (Stream : access Ada.Streams.Root_Stream_Type'Class; Element : in ASIS.Element); procedure Read (Stream : access Ada.Streams.Root_Stream_Type'Class; Library : in ASIS.Library; Element : out ASIS.Element); procedure Input (Stream : access Ada.Streams.Root_Stream_Type'Class; Library : in ASIS.Library) return ASIS.Element; end Asis.Element_Io; These four subprograms completely eliminate the need for the ASIS.Id package and eliminate the need for the ASIS.Id type, the ASIS.Id_Segment type, and the ASIS.Id_Segment_List type. Applications that just want to do I/O (seems to be the majority for our customers) simply use these and never bother to explicitly generate any ASIS.Id values (both a time and space optimization). Applications that want to have in-memory "pure" (no access value) records (perhaps for the purpose of reading/writing those records to a mixed type "database" of some form, simply use these routines and provide a Stream value that reads/writes to/from memory. ASIS could even provide the code for the to/from memory reads and writes. The coding is highly trivial and could be provided in the public domain by the ASISWG and the 20 or 30 lines of code required could simply be included into every ASIS implementation. (50 lines of code if you pretty-print it and comment it up very nicely.) Gary From roby Fri Jul 12 07:05:34 1996 Return-Path: From: roby (Clyde Roby) Subject: Id's and Id_Segment's (fwd) To: asis-technical@sw-eng.falls-church.va.us Date: Fri, 12 Jul 1996 07:05:31 -0400 (EDT) Cc: roby (Clyde Roby) Content-Type: text/plain; charset=US-ASCII Content-Length: 25114 X-Lines: 565 Status: OR All, This will be the next issue added to the ASIS Issues list (I'll add it early next week). This is an excellent discussion of how Id's and Id_Segment's were originally included in ASIS83 and why there may be no further need for them in ASIS95. Comments are welcome; please direct them to ASIS-Technical. Clyde ------- Date: Thu, 11 Jul 1996 16:29:43 +0200 From: Jesper Joergensen To: roby@ida.org Subject: Id's and ID_Segment's Hi Clyde, When I started reading the ASIS spec, I had difficulties seeing what ID_Segments ahere intended to be used for. I asked Steve Blake and Gary Barnes. From the answers I got, it seems that ID_Segments as well as Ids are superfluous when dealing with Ada 95. There, I propose to remove them from ASIS-95. Steve Blake suggested that I submitted this to you as an issue. That is hereby done. Below is the email communi- cation, that I have had with Gary Barnes on the subject. /Jesper jj -> geb, 1996-06-27 Sorry for disturbing you with this. I have asked Steve Blake about the semantics and intentions of Id_Segments in ASIS. It seems he would rather have you answer. Therefore I include my email communication with him and hope you will find the time to clarify things. There are two emails both from Steve to me but with my original emails quoted in the top, so everything should be there. ------------------------- Steve -> Jesper ------- >I'm the guy that went to Ada Europe and gave the talk on ASIS, that you >were originally supposed to give. I also went to the ASISWG meeting. > >As you may know, we have just started implementing ASIS for our Ada 95 >compilers. > >After having read the ASIS 2.0.G I have a question that noone could >answer at the ASISWG meeting, so they suggested that I ask you: what >are ID_Segments and what are they intended for. I can't find any >explanation on them in the specification itself (this is, of course, >not the same as it isn't there). > >/Jesper, DDC-I Jesper, sorry for the delay in my reply. You are right, There is very little explanation for them. They are intended to be a means of "flattening" ASIS.Ids which might contain access types in their vendor representation. Writing Ids with such access types to a file would obviously have no meaningful value if later read and applied to another invocation of ASIS. So this is provided as an alternative to users to guarantee the persistentcy of ids. Depending on you id implementation, you may need to create an Id_Segment bu slurping in all the id information and ensuring it to be persistent by adding additional information. The Id_Segment itself might just be a series of integers enough to hold the info. It can be written and read, and then converted back to an Id. In the TeleSoft ASIS implementation, we did not have any access types in our ids, so we just used a constrained array of integers large enough to hold the id value, and did unchecked conversions back and forth. The concept is similar to that of Asis.Portable_Transfer. Let me know if this makes sense or not. Another person to ask would be Gary Barnes at Rational. He wrote this part of ASIS. Steve Blake ------------------------ also Steve -> Jesper -------- >But as I read the requirements in Asis.Ids, in particular that an Id can be >written to a file, later read in again and converted to an Element, it >would not be a "legal" implementation to write out access type values in an >Id. I don't see that Asis.Ids allows that this is only possible in the same >invocation of Asis, but perhaps this was in fact the intention? > >/Jesper Yes, I got the same impression reading this again the other day. I believe you guessed the intention. I can't find any archive discussion of the subject. Have you tried Gary Barnes (geb@rational.com)? Steve Thanks, Jesper ===================== geb -> jj,sblake 1996-06-27 I realize that you know most of this, but bear with me for the purposes of a coherent exposition. ASIS is a facility for walking a series of tree (circular DAG if you prefer) data structures. Each structure represents some Ada unit that makes up some part of an Ada program, programs, "library", or in Ada 95, "environment". As an ASIS application walks overs the trees, at any given moment it has in its possession an "Element" of that tree. That Element is how the application communicates with ASIS and it is how the application tells ASIS "Here, this is where I am asking the question. What is the of this position in the tree of this unit?" Certain applications exist that have a need (or simply the desire) to record an Element (a library, a tree, and a tree position) for later use by some other application or even by another future instance of the same application. An example might be a theorm prover that wants to be able to work incrementally. It would take snapshots of its progress by taking note of "where" it was in its analysis and it would be able to restart the analysis from that place. Thus giving it flexibility in the face of hardware failures and whatnot. The basic need is to take an Element, or some sort of "reference" to an Element, and be able to write that Element/reference to some sort of I/O or storage device and to be able to read such an Element or reference after it has been written. Elements are very dynamic entities. In particular, they will of necessity always contain access values. (Or, they may contain the functional equivalent of access values. For example, it is possible to simulate access values by storing array indexes instead of access values.) ASIS.Compilation_Units (or ASIS.Units in ASIS'95-speak) are guaranteed to contain access values (or simultated access values). Why? Because An ASIS.Library is opened, and ASIS.Compilation_Unit values are obtained from those libraries and it is possible to get back to the Library from the Compilation_Unit value. That implies some sort of circular reference between the two. (Note: It is conceivable that an library could be implemented as some sort of "pool" of unit values, perhaps even a slice of some huge array of all possible unit values, and then a unit value is nothing more than an index into this array. And then to determine the library for a unit it is then simply necessary to figure out from a table what library corresponds to some unit array index. However, such an implementation is hightly unlikely simply from a storage utilization standpoing. (Huge arrays being allocated and reallocated and reallocated as new libraris are opened.) So it is possible to imagine an implementation of Units that did not actually contain circular references back to Libraries, but the chances of anyone being able or willing to actually use such an implementation is slight. ) Continuing on, ASIS.Elements are guaranteed to contain access values (or simulated access values)? Why? For the same reason. Elements are ultimately obtained by first obtaining a Unit. The Unit is then queried to get the root Declaration Element of the unit. All other Elements of that Unit are then obtained by starting at that root and traversing the Unit tree. And, is is possible to ask the question "What Unit are you from?" for all Element values. This implies some sort of circular reference between the two. (Note: Like with Units, it is possible to imagine implementations where the circularity is implicit in the location of the Element data rather than explicit within the Element itself. However, such implementations are very unlikely. Also, it doesn't matter that such implementations are merely unlikely. All that matters is that known existing Ada librarian implementations don't and won't use such implicit circularities. I don't mean ASIS implementation, I'm talking about the existing Ada librarian facilities of various vendors. The underlying librarian data structures upon which ASIS is merely implemented, and which ASIS data structures directly reference, are implemented in this fashion and ASIS data structures in fact end up with (real or simulated) access values pointing to these librarian data structures. ) The purpose of saying all of that about circular data references is simply to say that ASIS data structures (Library, Compilation_Unit, and Element) are not suitable for direct use with any ordinary I/O facility such as Text_Io, Sequential_Io, Direct_Io, or anything else that would normally be found in the average operating system. The reason they are not suitable for such I/O is that they contain dynamic access values that will not be valid when read by some other application or by some other instance of the same application. Because of this, it was necessary to design some facility that would allow applications to read and write some sort of "reference" to ASIS.Element values. The abstraction that resulted is the ASIS.Id data type. That is why ASIS.Ids exist. In order to understand why ASIS.Id_Segments exist we must first discuss other parts of ASIS. ASIS requires an implementation to provide access to various Elements that may not have any direct physical existence in the underlying Ada librarian. These things are documented in the various documents that I authored while I was helping with ASIS v1.1.1. Examples of such things include, but are not limited to: - Elements of declarations of derived subprograms. An Ada compiler does not need to actually build declarations for these. There are techniques for correctly performing Ada compilation by sharing the declarations of the original subprogram. However, ASIS requires that there appear to be such derived declarations and it requires that they not be Asis.Elements.Is_Equal to the original declarations. So some ASIS implementations will have to simulate the existence of these compiler-unnecessary declarations. - Elements of declarations of implicit builtin operators and attribute functions are likewise often completely unnecessary from the viewpoint of a compiler. However such things are deemed necessary from the viewpoint of an ASIS application. So once again there exist things which will have to be simulated by some ASIS implementations. - Elements of generic instances are particularly troublesome. Generic instance specifications are very likely to exist in all librarians. It is extremely difficult, perhaps impossible, to correctly compile Ada programs without performing the equivalent of macro expanding a generic specification at the site of each and every generic instantiation. From an ASIS perspective, difficulties occur when a compiler or librarian decides to share the expanded instance specification between two different instantiations. At that point the ASIS.Element values from the two separate instance must test as no ASIS.Elements.Is_Equal and yet the underlying librarian data structure is identical. So this is yet another simulation. Also from an ASIS perspective, difficulties occur with "shared code" generics. These are generics which are compiled into executable code exactly once. And each and every instantiation of that generic invokes exactly the same code. Such code is capable of correctly executing regardless of the generic formal types or procedures. In cases like this, there is no macro expanded generic body for any of the generic instances. And yet, ASIS requires (quite reasonably so in my opinion) that every instance have not only an implicit specification but also and implict body and that both of these be fully traversable. (Of course, to traverse them, the body of the generic as well as the generic instance must have been compiled.) This implies that there is likely to be (at least in some ASIS implementations) a great deal of generic instance simulation going on. And, since generic's can instantiate other generics, such simulation is recursive. A simulating implementation will have to be able to simulated a simulted instance inside another simulated instance inside another simulated instance inside ... The fact that some Elements need to be simulated is not necessarily a problem. Each of the places in ASIS where an ASIS implementation *might* be forced to provide a simulation, the ASISWG was very very very careful. In each of the situations, except for generic instances, the degree of potential simulation was very very very restricted. In fact, except for generic instances, each simulation could be easily and correctly performed a tiny finite-state-machine. This allows each Element value, except for generic instances, whether simulated or not, to be represented by a single non-heap-based variant record. This allowed three vital things. First, it meant that ASIS.Element values could be simple variant record types. Second, because they could be simple variant record types, it was possible for Ada functions to return such values and to return unconstrained arrays of such values. This was vitally important because it meant that Element values did not need to be heap based (they did not need to be implemented as access values). Third, because they did not need to be implemented as access values by any implementation, there did not need to be ASIS facilities for deallocating those values. And that meant that use of the ASIS facilities would be *tremendously* easier. There were no storage leaks to worry about. None whatsoever. A major source of bugs in any program was completely eliminated. However, generic instance simulations are a problem. As I mentioned above, a simulated instance may need to "contain" other simulated instances which contain other simulated instances...to an arbitrary level. If we ignore nested generic instances, simulating an expanded generic instance, eithe specification or body, is not terribly difficult. It can be tedious but it is not difficult. This is exactly what all of the Rational ASIS implementations do. The simulation simply has a) a pointer into the generic template specification or body whose expansion is being simulated, b) a pointer to the semantic context where the generic was instantiated, and c) a pointer to the semantic information for the arguements of the instance. Except for the very few ASIS semantic interfaces (such as Expression_Type or Name_Definition) the simulation is trivial. And even the semantic portions are more tedious than complicated. However, when we consider simulating nested generic instances, we suddenly realize that we need the data for a, b, and c that we had before, but we also neee d) a pointer to the outer generic instance context. And we even need e) a pointer to the context outside of that, and f) a pointer to the context outside of that, and g) .... We end up needing, in essense, a linked list of nested generic instance contexts. This also means that either a) an ASIS.Element is no longer of bounded length and so cannot be an element of an array (and the entire ASIS interface design falls apart), or b) certain ASIS.Element values must now contain access values (or simulated equivalents) in order to be able to reference variably sized and variably nested simulated generic instance contexts. This means that the data for an ASIS.Element is (sometimes) no longer fully contained by the ASIS.Element data value itself, and that the data that represents an ASIS.Element value is (sometimes) of very great and variable size. And given that, we get back to the concept of ASIS.Id. An ASIS.Id is a value that can be used by the ASIS implementation to reconstruct the ASIS.Element value that was used to create the ASIS.Id in the first place. Since the ASIS.Element value is not guaranteed to be of a single fixed maximum size (or since that maximum size is potentially very very very large, thousands of bytes per Element) it is no longer possible to guarantee (or at least, it is not longer desirable) that every ASIS.Id value is the same maximum size. Because ASIS.Elements vary in actual size, ASIS.Ids vary in actual size. And yet, the ASIS interface still wants to return ASIS.Id values and even perhaps arrays of ASIS.Id values. We wanted code to look like this: declare A : Asis.Element := ASIS.Some_Interface (...); B : Asis.Element; C : Asis.Id := ASIS.Some_Other_Interface (...); D : Asis.Id; begin while ... loop B := Asis.Some_Third_Interface (A); if ... then D := C; else D := ASIS.Some_Fourth_Interface (...); end if; ...code using A, B, C, and D... end loop; end; because such code is vastly easier to write and maintain than code like this: declare A : constant Asis.Element := ASIS.Some_Interface (...); C : constant Asis.Id := ASIS.Some_Other_Interface (...); procedure Confusing (B : Asis.Element; D : Asis.Id) is begin ...code using A, B, C, and D... end Confusing; begin while ... loop declare B : constant Asis.Element := Asis.Some_Third_Interface (A); begin if ... then Confusing (B, C); else Confusing (B, ASIS.Some_Fourth_Interface (...)); end if; end; end loop; end; Ada does not make it convenient to handle and pass around variable sized data values that are not fully contained by a variant record. ASIS provides a facility for reading and writing these variable sized ASIS.Id values. Those facilities are sufficient for any application that merely wants to be able to store ASIS.Id values in some file that contains nothing but ASIS.Id values. And, there are a number of applications that are fully satisfied by those facilities. However, there exist applications that want to store ASIS.Id values (or their equivalent) in files that contain other data types as well. Ada 83 does not provide any facilites for files that contain more than one data type (unless you convert each data type to a string or some other "stream" representation and then read/write that other representation). Ada 95 on the other hand provides the I/O stream concept and implicit conversion facilities to/from that I/O stream. So Ada 95 is much simpler. But, the ASIS v1.1.1 design was for Ada 83, so back to that discussion... For applications that wanted either a) the ability to write out ASIS.Id values to files that contain mixed data or b) the ability to create "pure" (not access values) record types of their own, which could then be read/written to/from files, it was necessary to have some form of ASIS.Id that could be used in this fashion. That is where ASIS.Id_Segment and ASIS.Id_Segment_List came in. This gave the application the ability to obtain a "pure" (no access values or simulated access values) data value that represented an ASIS.Element. The application could then read/write that pure value or it could store that value into pure data types of the application's own devising. This was considered to be a crucial facility. And, our customers have made extensive use of this facility. With Ada 95, the ASIS.Id_Segment and ASIS.Id_Segment_List facilities are no longer necessary. They can be replaced with Ada.Stream facilities. The ASIS specification merely needs to require that the ASIS implementation provide ASIS.Id, 'Write, 'Input, and 'Output facilities. The application can then create its own memory-to-memory Ada.Stream derivative type that is then used to "read" or "write" and ASIS.Id values into Ada.Streams.Stream_Element_Array. And in fact, the Asis.Id facilities of ASIS v1.1.1 could be eliminated completely and replaced by ASIS.Element'Write, 'Read, 'Input, 'Output. Those would simulataneously give the ability to read/write complete Element values and the ability to create in-memory pure value equivalents for Element values. The ASIS implementation of the attribute functions would provide the equivalent of the current ASIS facilities. Asis.Element <=> Asis.Id <=> Asis.Id_Segment_List facilities) And that is the history and rationale behind ASIS.Id_Segment and ASIS.Id_Segment_List. Vital for Ada 83, unnecessary for Ada 95. Gary ================================= jj -> geb,sblake 1996-06-28 Gary, Thanks for a very, very thorough explanation on id_segments. Let's see if I understood correctly: 1. Id segments (and lists of them) are not necessary in ASIS for Ada 95, 2. In ASIS for Ada 83 they were actually only necessary for implementations that share code for generics. Implementations that macro expand specifications AND bodies for generic instances don't need them. As I understand, you would propose to get rid of id_segments in ASIS 95. /Jesper =================================== geb -> jj 1996-06-28 > Gary, > > Thanks for a very, very thorough explanation on id_segments. Let's see > if I understood correctly: > > 1. Id segments (and lists of them) are not necessary in ASIS for Ada 95, Correct. > 2. In ASIS for Ada 83 they were actually only necessary for > implementations that share code for generics. Implementations that > macro expand specifications AND bodies for generic instances don't > need them. No. Some compilers never generate (and/or retain) expanded generic bodies. Shared code generics are merely the most likely reason for such a thing. And, it has nothing to do with ASIS implementations. They exist for *applications*, not *implementations*. They were necessary for ASIS-using *applications* that want to do certain varieties of operations portably. Applications that wanted either a) to have binary files containing mixed data types including ASIS.Id values, or b) to have record (or array) types that were "pure" (guarenteed to contain no access values, meaning that they can be read/written to files without worry about invalidating hidden pointer values). Without the Id_Segment{_List} type(s), such portable applications would have been *impossible*. Not hard, not difficult, literally *impossible*. That is why they existed. > As I understand, you would propose to get rid of id_segments in ASIS 95. More than that. I would eliminate the ASIS.Id type as well. All ASIS has to do is the equivalent of specifying that ASIS.Element'Write, 'Read, 'Input, and 'Output exist and that they do what ASIS.Id's did before. That is, they provide a way to create a "reference" to an ASIS.Element value that can be written, and then later read and, by being read, that reference is automatically converted back into an Element value. For the purposes of 'Read and 'Input, which do *not* and *can* not have an ASIS.Library parameter, this would require that ASIS have some sort of "current Library for I/O" concept/interal-state. But it completely eliminates the entire ASIS.Id package and eliminates the need for the application to deal with the concept of ASIS.Id at all. Of course ASIS could have the following, which would probably be better than defining 'Write, 'Read, 'Input, and 'Output because this way the ASIS library does not have to contain state: package Asis.Element_Io is procedure Write (Stream : access Ada.Streams.Root_Stream_Type'Class; Element : in ASIS.Element); procedure Output (Stream : access Ada.Streams.Root_Stream_Type'Class; Element : in ASIS.Element); procedure Read (Stream : access Ada.Streams.Root_Stream_Type'Class; Library : in ASIS.Library; Element : out ASIS.Element); procedure Input (Stream : access Ada.Streams.Root_Stream_Type'Class; Library : in ASIS.Library) return ASIS.Element; end Asis.Element_Io; These four subprograms completely eliminate the need for the ASIS.Id package and eliminate the need for the ASIS.Id type, the ASIS.Id_Segment type, and the ASIS.Id_Segment_List type. Applications that just want to do I/O (seems to be the majority for our customers) simply use these and never bother to explicitly generate any ASIS.Id values (both a time and space optimization). Applications that want to have in-memory "pure" (no access value) records (perhaps for the purpose of reading/writing those records to a mixed type "database" of some form, simply use these routines and provide a Stream value that reads/writes to/from memory. ASIS could even provide the code for the to/from memory reads and writes. The coding is highly trivial and could be provided in the public domain by the ASISWG and the 20 or 30 lines of code required could simply be included into every ASIS implementation. (50 lines of code if you pretty-print it and comment it up very nicely.) Gary From cooper@longshot.ds.boeing.com Fri Jul 12 21:10:49 1996 Return-Path: Received: from ida.org (cs.ida.org) by csed-115.csed.ida.org (4.1/SMI-4.1) id AA09662; Fri, 12 Jul 96 21:10:49 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA20002; Fri, 12 Jul 96 21:10:48 EDT Received: from atc.boeing.com by sw-eng.falls-church.va.us (8.7.1/) id AAA07634; Sat, 13 Jul 1996 00:35:21 GMT Received: by atc.boeing.com (5.65/splinter.boeing.com) id AA12126; Fri, 12 Jul 1996 17:35:25 -0700 Received: from longshot.ds.boeing.com by splinter.boeing.com with ESMTP (1.37.109.16/16.2) id AA039258144; Fri, 12 Jul 1996 17:35:45 -0700 Received: by longshot.ds.boeing.com (SMI-8.6/SMI-SVR4) id RAA09740; Fri, 12 Jul 1996 17:36:32 -0700 Date: Fri, 12 Jul 1996 17:36:32 -0700 From: cooper@longshot.ds.boeing.com (Dan Cooper) Message-Id: <199607130036.RAA09740@longshot.ds.boeing.com> To: ASIS-technical@sw-eng.falls-church.va.us Subject: Re: Id's and Id_Segment's (fwd) X-Sun-Charset: US-ASCII Content-Length: 1181 X-Lines: 28 Status: OR Clyde, > This will be the next issue added to the ASIS Issues > list (I'll add it early next week). This is an excellent > discussion of how Id's and Id_Segment's were originally > included in ASIS83 and why there may be no further need for > them in ASIS95. Comments are welcome; please direct them to > ASIS-Technical. I think this is an excellent issue to be added to our list. But beyond that: it includes a lot of foundational thought that should be enlightening to ASIS newcomers, and especially to ASIS implementors. > And that is the history and rationale behind ASIS.Id_Segment and > ASIS.Id_Segment_List. Vital for Ada 83, unnecessary for Ada 95. This presentation should definitely be captured and documented as part of "the history and rationale behind ASIS" not just for Ids but also for the ASIS interface design generally. 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 cooper@longshot.ds.boeing.com Tue Jul 23 16:30:05 1996 Return-Path: Date: Tue, 23 Jul 1996 12:42:51 -0700 From: cooper@longshot.ds.boeing.com (Dan Cooper) To: ASIS-technical@sw-eng.falls-church.va.us Subject: Re: removal of Id's and Id_Segment's Content-Length: 3668 X-Lines: 74 Status: OR Clyde, > Since we have not seen any further discussion about the > proposal to remove Id's and Id_Segment's and their related > packages from ASIS, we are assuming that there are no major > objections against the proposal. Therefore, they will be > removed from ASIS. My understanding of Gary Barnes' argument was twofold: 1) that ASIS should remove the Id stuff, but also 2) add a quartet of IO attributes or subprograms to support streaming: so his proposal is not just *deletion* but rather *replacement*. Here's the relevant part of his email: > > As I understand, you would propose to get rid of id_segments in ASIS 95. > > More than that. I would eliminate the ASIS.Id type as well. > > All ASIS has to do is the equivalent of specifying that ASIS.Element'Write, > 'Read, 'Input, and 'Output exist and that they do what ASIS.Id's did before. > That is, they provide a way to create a "reference" to an ASIS.Element value > that can be written, and then later read and, by being read, that reference is > automatically converted back into an Element value. > > For the purposes of 'Read and 'Input, which do *not* and *can* not have an > ASIS.Library parameter, this would require that ASIS have some sort of > "current Library for I/O" concept/interal-state. But it completely eliminates > the entire ASIS.Id package and eliminates the need for the application to deal > with the concept of ASIS.Id at all. > > Of course ASIS could have the following, which would probably be better than > defining 'Write, 'Read, 'Input, and 'Output because this way the ASIS library > does not have to contain state: > > package Asis.Element_Io is > procedure Write (Stream : access Ada.Streams.Root_Stream_Type'Class; > Element : in ASIS.Element); > procedure Output (Stream : access Ada.Streams.Root_Stream_Type'Class; > Element : in ASIS.Element); > > procedure Read (Stream : access Ada.Streams.Root_Stream_Type'Class; > Library : in ASIS.Library; > Element : out ASIS.Element); > function Input (Stream : access Ada.Streams.Root_Stream_Type'Class; > Library : in ASIS.Library) > return ASIS.Element; > end Asis.Element_Io; > > These four subprograms completely eliminate the need for the ASIS.Id package > and eliminate the need for the ASIS.Id type, the ASIS.Id_Segment type, and the > ASIS.Id_Segment_List type. > > Applications that just want to do I/O (seems to be the majority for our > customers) simply use these and never bother to explicitly generate any > ASIS.Id values (both a time and space optimization). > > Applications that want to have in-memory "pure" (no access value) records > (perhaps for the purpose of reading/writing those records to a mixed type > "database" of some form, simply use these routines and provide a Stream value > that reads/writes to/from memory. > > ASIS could even provide the code for the to/from memory reads and writes. The > coding is highly trivial and could be provided in the public domain by the > ASISWG and the 20 or 30 lines of code required could simply be included into > every ASIS implementation. (50 lines of code if you pretty-print it and > comment it up very nicely.) > > Gary 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 roby Tue Jul 23 17:02:49 1996 Return-Path: Date: Tue, 23 Jul 96 17:02:48 EDT From: roby (Clyde Roby) To: cooper@longshot.ds.boeing.com Subject: Re: removal of Id's and Id_Segment's Cc: roby, ASIS-Technical@SW-Eng.Falls-Church.Va.US Content-Length: 441 X-Lines: 12 Status: OR Dan, > My understanding of Gary Barnes' argument was twofold: 1) that ASIS > should remove the Id stuff, but also 2) add a quartet of IO attributes > or subprograms to support streaming: so his proposal is not just > *deletion* but rather *replacement*. Here's the relevant part of > his email: Yes, you're right. Instead of simply deleting the Id stuff, we would replace it with the subprograms described in the original post. Clyde From dhe@cyberport.net Tue Jul 23 17:53:50 1996 Return-Path: Date: Tue, 23 Jul 96 15:00:49 MDT From: "Dan Ehrenfried" Subject: Re: removal of Id's and Id_Segment's Reply-To: dhe@cyberport.net To: "Dan Cooper" , ASIS-technical@sw-eng.falls-church.va.us Content-Length: 4504 X-Lines: 103 Status: OR >Clyde, > >> Since we have not seen any further discussion about the >> proposal to remove Id's and Id_Segment's and their related >> packages from ASIS, we are assuming that there are no major >> objections against the proposal. Therefore, they will be >> removed from ASIS. Well I guess I should look at my ASIS mail more closely. I am glad that I read this by chance. Asis.Id is of fundamental importance to my implementation of the Ada Analyzer. I use them as a way to keep maps of elements that I have already seen while processing. The fundamental requirement is that an Id be unique for each element. It is also better if Ids are small. If there is another mechanism in ASIS that provides this capability, then I could switch to it. Without it, ASIS would not be complete and I would not be able to implement an important reason why ASIS exists in the first place. I think that Asis.Id or an equivalent mechanism MUST be part of ASIS. dan ehrenfried > >My understanding of Gary Barnes' argument was twofold: 1) that ASIS >should remove the Id stuff, but also 2) add a quartet of IO attributes >or subprograms to support streaming: so his proposal is not just >*deletion* but rather *replacement*. Here's the relevant part of >his email: > >> > As I understand, you would propose to get rid of id_segments in ASIS 95. >> >> More than that. I would eliminate the ASIS.Id type as well. >> >> All ASIS has to do is the equivalent of specifying that ASIS.Element'Write, >> 'Read, 'Input, and 'Output exist and that they do what ASIS.Id's did before. >> That is, they provide a way to create a "reference" to an ASIS.Element value >> that can be written, and then later read and, by being read, that reference is >> automatically converted back into an Element value. >> >> For the purposes of 'Read and 'Input, which do *not* and *can* not have an >> ASIS.Library parameter, this would require that ASIS have some sort of >> "current Library for I/O" concept/interal-state. But it completely eliminates >> the entire ASIS.Id package and eliminates the need for the application to deal >> with the concept of ASIS.Id at all. >> >> Of course ASIS could have the following, which would probably be better than >> defining 'Write, 'Read, 'Input, and 'Output because this way the ASIS library >> does not have to contain state: >> >> package Asis.Element_Io is >> procedure Write (Stream : access Ada.Streams.Root_Stream_Type'Class; >> Element : in ASIS.Element); >> procedure Output (Stream : access Ada.Streams.Root_Stream_Type'Class; >> Element : in ASIS.Element); >> >> procedure Read (Stream : access Ada.Streams.Root_Stream_Type'Class; >> Library : in ASIS.Library; >> Element : out ASIS.Element); >> function Input (Stream : access Ada.Streams.Root_Stream_Type'Class; >> Library : in ASIS.Library) >> return ASIS.Element; >> end Asis.Element_Io; >> >> These four subprograms completely eliminate the need for the ASIS.Id package >> and eliminate the need for the ASIS.Id type, the ASIS.Id_Segment type, and the >> ASIS.Id_Segment_List type. >> >> Applications that just want to do I/O (seems to be the majority for our >> customers) simply use these and never bother to explicitly generate any >> ASIS.Id values (both a time and space optimization). >> >> Applications that want to have in-memory "pure" (no access value) records >> (perhaps for the purpose of reading/writing those records to a mixed type >> "database" of some form, simply use these routines and provide a Stream value >> that reads/writes to/from memory. >> >> ASIS could even provide the code for the to/from memory reads and writes. The >> coding is highly trivial and could be provided in the public domain by the >> ASISWG and the 20 or 30 lines of code required could simply be included into >> every ASIS implementation. (50 lines of code if you pretty-print it and >> comment it up very nicely.) >> >> Gary > >C. Daniel Cooper ================================================ >Adv Computing Technologist | processes | all opinions are | >206-655-3519 | + architectures | strictly my own, | >Cooper@Boeing.com | = systems | NOT my employers | >================================================================= > Dan Ehrenfried dhe@littletree.com (406) 854-2160 (406) 854-2170 (fax) From danr@tawny.ssd.hcsc.com Tue Jul 23 18:22:55 1996 Return-Path: Received: from ida.org (cs.ida.org) by csed-115.csed.ida.org (4.1/SMI-4.1) id AA24108; Tue, 23 Jul 96 18:22:54 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA25582; Tue, 23 Jul 96 18:22:45 EDT Received: from hawk.hcsc.com by sw-eng.falls-church.va.us (8.7.1/) id VAA23188; Tue, 23 Jul 1996 21:29:59 GMT Received: from tawny.ssd.hcsc.com by hawk.hcsc.com (5.61/harris-5.1) id AA04656; Tue, 23 Jul 96 17:30:41 -0400 Received: by tawny.ssd.csd.harris.com (5.61/CX/UX-7.1) id AA12653; Tue, 23 Jul 96 17:30:39 -0400 From: danr@tawny.ssd.hcsc.com (Dan Rittersdorf) Message-Id: <9607232130.AA12653@tawny.ssd.csd.harris.com> Subject: Re: removal of Id's and Id_Segment's To: dhe@cyberport.net Date: Tue, 23 Jul 1996 17:30:39 -0400 (EDT) Cc: cooper@longshot.ds.boeing.com, ASIS-technical@sw-eng.falls-church.va.us In-Reply-To: from "Dan Ehrenfried" at Jul 23, 96 03:00:49 pm Reply-To: Dan.Rittersdorf@mail.hcsc.com X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1992 X-Lines: 49 Status: OR Dan(s), Clyde, > > >Clyde, > > > >> Since we have not seen any further discussion about the > >> proposal to remove Id's and Id_Segment's and their related > >> packages from ASIS, we are assuming that there are no major > >> objections against the proposal. Therefore, they will be > >> removed from ASIS. > > Well I guess I should look at my ASIS mail more closely. I am glad that > I read this by chance. > > Asis.Id is of fundamental importance to my implementation of the Ada > Analyzer. I use them as a way to keep maps of elements that I have already > seen while processing. > This is an attribute of ID's that I haven't seen mentioned in previous posts rehashing their purpose. Id's are able to be used for persistent storage (i.e. I/O) of elements *because* they are unique. The ability to obtain a unique identifier for an ID which can later be used to obtain the element that the ID refers to is important whether I/O facilities are used or not, and should remain in ASIS. It is questionable whether ASIS should provide such services as hashing ID's, as it did in 1.1.1. I agree that the I/O portion of ID's and ID segments should be replaced with the Ada 95 Streams based facilities iff it also provides the ability to obtain the same element on a subsequent ASIS application run, as is provided by the current ID's facility. > I think that Asis.Id or an equivalent mechanism MUST be part of ASIS. > > dan ehrenfried > (Back to my hole...) -- ______________________________________________________________________________ Dan.Rittersdorf@mail.ccur.com | Daniel G. Rittersdorf Concurrent Computer Corporation | 178 Washington Street 2101 W. Cypress Creek Rd. | Sparta, MI 49345-1324 Ft. Lauderdale FL 33309 | Ph: +1 (616) 887-5431 ______________________________________________________________________________ From dhe@cyberport.net Mon Jul 29 18:08:56 1996 Return-Path: Received: from ida.org by csed-115.csed.ida.org.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA02720; Mon, 29 Jul 1996 18:08:54 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA03106; Mon, 29 Jul 96 18:08:54 EDT Received: from cpmt2.cyberport.net by sw-eng.falls-church.va.us (8.7.1/) id VAA22829; Mon, 29 Jul 1996 21:35:55 GMT Received: from cyb-pm1-002.cyberport.net (cyb-pm1-014.cyberport.net [204.94.49.74]) by cpmt2.cyberport.net (8.6.9/8.6.9) with SMTP id PAA07744 for ; Mon, 29 Jul 1996 15:37:11 -0600 Message-Id: Date: Mon, 29 Jul 96 15:35:46 MDT From: "Dan Ehrenfried" Subject: Asis.ids Reply-To: dhe@cyberport.net To: asis-technical@sw-eng.falls-church.va.us X-Mailer: VersaTerm Link v1.1.5 Content-Length: 1321 X-Lines: 38 Status: OR > >Clyde, > > > >> Since we have not seen any further discussion about the > >> proposal to remove Id's and Id_Segment's and their related > >> packages from ASIS, we are assuming that there are no major > >> objections against the proposal. Therefore, they will be > >> removed from ASIS. > > Well I guess I should look at my ASIS mail more closely. I am glad that > I read this by chance. > > Asis.Id is of fundamental importance to my implementation of the Ada > Analyzer. I use them as a way to keep maps of elements that I have already > seen while processing. > > I think that Asis.Id or an equivalent mechanism MUST be part of ASIS. > > dan ehrenfried > I have exchanged mail with Gary Barnes about the use of the Asis.Id type. He convinced me that the byte_stream type and the result of Asis.Element'Output would provide the equivalent functionality of a unique value for each Asis element. Asis.Element could also be used if a hash function were provided. All of these solutions are inefficient for the uniqueness requirement, that is they contain more data than is required for uniqueness. It would be nice to define a separate mechanism (type and hash function) that would provide a minimal unique value for each element. Dan Ehrenfried dhe@littletree.com (406) 854-2160 (406) 854-2170 (fax)