Version 1.3 of si99s/si99-0062-1.txt

Unformatted version of si99s/si99-0062-1.txt version 1.3
Other versions for file si99s/si99-0062-1.txt

!standard 23          10-02-23 SI99-0062-1/03
!class amendment 10-01-26
!status work item 10-01-26
!status received 09-11-03
!priority Medium
!difficulty Easy
!qualifier Omission
!subject Comments on the ASIS semantic subsystem
!summary
Various changes are made.
!question
(See discussion.)
!recommendation
(See summary.)
!wording
*** TBD ***
!discussion
Following are all of the technical comments filed by Gary Barnes (via SIGAda) on the ASIS CD in 2009 after November 1st. His comments came too late to include in the November SI. They are marked with [GB:] (as we already have a "Gary" on the ARG). (He also noted a number of typos, which have been fixed without comment as the CD did not match the intent shown in the appropriate SI.)
23.2.10, 23.2.13, 23.2.14, 23.3.4, 23.4.7, 23.4.8, 23.5.6, 23.8.4, 23.11.9, 23.12.7, 23.13.2, and 23.14.2:
[GB:] The Ada code in these sections will not compile. The generic being instantiated all require a "=" operation that operates, specifically, on XXX_View'Class objects. Ada doesn't create those for free. So each one of these sections needs to specify an equality operator such as: Function "=" (L,R : Subtype_View'Class) return Boolean; Whose body is then simply "return L = R;".
lIn addition, several of the Vector types require a matching incomplete type declaration earlier in their respective packages because there are subroutine interfaces that want to be a primitive of the View class and yet they also need to refer to the Vector class. View_Declaration_Vector is one of the types affected.
[Randy:] Actually, Ada 2005 does create those "=" operators for free. We discovered this problem with this specification, noticed that this would be severe problem with using the indefinite containers as intended (as this package does) and thus we decided to fix the Ada language; AI05-0071-1 provides a binding interpretation that this "=" is automatically created. An implementation providing ASIS will clearly need to implement this AI (it also ought to implement the Holder container, which was designed in part to make ASIS semantic subsystem use easier). There probably ought to be an AASIS note to that effect.
The incomplete types actually appear in the packages (see SI99-0024-1), but they don't appear in the written description. The presumption is that it is always OK to add incomplete tagged types (as they can't change the semantics in a significant way) when creating the actual specification. Nothing in the standard claims that these declarations are directly compilable (note that this applies to many of the following comments as well). But perhaps that is too obscure.
23.1.2:
[GB:] Why is the name "Discarded_Names" when the pragma is "Discard_Names"? The other pragmas all seem to have their real names used.
23.2.1:
[GB:] What is the result of (A = B) when both A and B are Views? This is not specified. While we might like to make the assumption that two Views that represent the same Asis.Element are "=" we cannot make this assumption.
It is reasonable to assume that a View will contain at least one field and that field is very likely to be an Asis.Element. The normal "=" operation between Asis.Element values is defined as not working. A/=B does not imply not Is_Equal(A,B). So for at least this reason it is necessary to define the meaning of A=B for two View values. Either (1) A=B is meaningless (which means that the standard needs to define an Is_Equal function) or (2) A=B does what we might hope it does (which means that the standard needs to specify this behaviour).
[Randy:] Probably should specify that A = B iff the A and B represent the same view. The same view clearly means the same element, but I don't think the reverse is true (multiple views could resolve to the same element, since views are Ada semantics, not Ada syntax, based).
---
[GB:] The current list of View interface types are very inconsistent and consequently needlessly confusing. Asis.Declarations are a separate hierarchy (type View_Declaration) while Asis.Expressions, Asis.Type_Definitions, and Asis.Statements are lumped into one hierarchy (type View). Either all Asis.Elements should be uniformly represented as part of a single hierarchy (as is done in Asis itself) or the hierarchies for disparate varieties of Element should be uniformaly separated. The current "type View;" and its subtypes represent three very separate classes of Element. This tabular presentation may make that more obvious. There are five (5) top level subtypes for Expression with one (1) each for Statement and Type_Definition.
View - any Expression, Statement, or Type_Definition
Callable_View - expression ref to callable Exception_View - expression ref to exception Generic_View - expression ref to generic Object_View - expression ref to object
Access_Object_View - expression ref to acc object
Package_View - expression ref to package Statement_View - a statement Subtype_View - any type_definition
Composite_Subtype - have components
Array_Subtype Tagged_Subtype
Elementary_Subtype
Scalar_Subtype Discrete_Subtype Access_Subtype Access_To_Object_Subtype Access_To_Subprogram_Subtype
It seems pointless to "combine" a "view" interface for Elements such as Expression, Statement, and Type_Definition and then have a separate "view" interface for Declaration elements.
I would like to see either of the following: a) separate hierarchies for separate concepts
type expression_view is interface; type subtype_view is interface; type statement_view is interface;
b) combine everything (which is more like what Asis.Element does in normal ASIS)
type view is interface; type expression_view is interface and view; type subtype_view is interface and view; type declaration_view is interface and view; type statement_view is interface and view;
[Randy:] (Based on similar ASIS subcommittee discussion:) A "view" represents a view of an entity in Ada semantics. These are all related, and share many operations involving declarations and visibility. (We're talking about "declarations" in an Ada, not an ASIS sense; ASIS gets this concept subtly wrong.) OTOH, a View_Declaration (which is a lousy name, IMHO) is refering to the declaration, not to any view. It can be thought of as "Declaration_of_View" (and perhaps it should be named that).
Note that it is possible to get both a View_Declaration and a View from the same element. The view is of the defining view of the declaration, while the View_Declaration is the declaration itself. These are not the same thing: the view depends on visibility; declarations do not (they always exist). In addition, there are many kinds of anonymous declarations/definitions for which there is no associated element.
It is important to remember that this subsystem is defined separately from the syntactic subsystem, other than for a few defined connections. An element-centric viewpoint is just going to confuse things worse than they are (if the element-centric viewpoint was adequate, we wouldn't have gone through the effort of defining this subsystem in the first place).
In any case, we may need to improve the description of the View and View_Declaration (and personally, I would change the name to Declaration_of_View, because I've been confused by the difference between these myself).
23.2.3:
[GB:] What does V.Convention_Identifier return when V.Convention = Unspecified_Convention?
Presumably this will be "" but it needs to be specified.
23.2.4 .. 23.2.14:
[GB:] Which sections comprise components of the Asis.Views.Declarative_Regions package and which ones do not? The text is anything but clear. It is very hard to implement a package when it isn't possible to tell what is part of the package.
23.2.4 says "The subpackage has the contents given in the following subclauses." But then is immediately followed by section 23.2.5. This leads to the conclusion that "the following subclauses" is intended to mean the 23.2.* clauses, all of which are to be included.
But that makes little sense. 23.2.13 and 23.2.14 would seem "clearly" to be components of Asis.Views instead. 23.2.12 interfaces have only View parameters and so it seems odd to have them inside Declarative_Regions. 23.2.11 might be inside Declarative_Regions but then that would make the Defined_Region subroutine a dispatching primitive. 23.2.10 would seem to be a plausible component of Asis.Views.Declarative_Regions.
So is 23.2.9 the "last" component? Are any of them components?
[Randy:] It 23.2.4 through 23.2.10. But That better be said somewhere.
23.2.11:
[GB:] If a previous comment is accepted and these interfaces are deemed to be part of Asis.Views and not part of Asis.Views.Declarative_Regions, then the result type of Declaration and of Defined_Region, a "View_Declaration'Class", will not be visible. Use Declarative_Regions.View_Declaration'Class instead.
[Randy:] This clause is one of the subjects of SI99-0054-1, it will be rewritten as part of that SI.
---
[GB:] What does Has_Declaration do?
"Function Has_Declaration returns True if and only if view V was defined
by a declaration."
What does that mean?
(I saw words in an SI that said something to the effect that a "view" as the
word is used here is intended to be a "view" as that word is used in the Ada Standard. So "defined" here is then supposed to mean something like "view as defined by the Ada Standard". But, if that is true, it is sad that this equation of concepts is never mentioned in the draft.)
View objects (Asis.Views.View values) are not "defined" by anything. A View is a value obtained (or created) by starting with some Asis.Element. There are interfaces for obtaining View values from Asis.Expression elements and interfaces for obtaining View values from Asis.Type_Definition elements. There are no interfaces for obtaining View values from Asis.Declarations or Asis.Defining_Names which could possibly be used to justify the word "defined".
Similarly, the Declaration interface in that same paragraph has the problem of, what does it really do? My guess at what these interfaces do is this:
Has_Declaration(V) returns True iff V.Element_Denoting_View is a suitable Element for passing to Asis.Expressions.Corresponding_Name_Definition.
Declaration(V) returns Asis.Expressions.Corresponding_Name_Definition(V.Element_Denoting_View);
Of course, if this is correct then there should also be a version of Declaration that returns a list of the declarations to which the expression refers, just like there is a Corresponding_Name_Definition_List interface.
If an implementor can't understand the interface, what chance does a user have? Indeed, what chance does a user have of achieving portability.
[Randy:] The ASIS standard says in 1.3 that the "terms and definitions" from the Ada standard apply (unless ASIS defines the term itself). So that's a blanket rule that do not need to be (and shouldn't be) repeated everywhere.
It wouldn't hurt to have more AASIS material on the model, but it doesn't belong in the standard.
Otherwise, this entire section is scheduled to be rewritten by SI-54; we'll need to revisit these concerns once that is done.
23.2.12:
[GB:] For Is_Aspect_Directly_Specified for Implementation_Defined_Aspect_Kinds, the textual description is missing the phrase "the declaration of" for "is directly specified for the declaration of the view". Also "the named aspect" should be "the Aspect named" in order to match the previous function of the same name.
23.4.2 and 23.4.4
[GB:] There appears to be no difference between Are_Of_Same_Type and Is_Descendant. Both are defined in terms of equality of the actual type referenced by the subtypes. I suspect that this is an error and that Is_Descendant is intended to be more of a question about whether one subtype was used in the declaration of another where Are_Of_Same_Type is already presumed to be True.
[Randy:] Is_Descendant appears to be the descendant relationship (and is asymetrical for that reason), while Are_of_Same_Type is symetrical. In particular, If Is_Descendant(A, B) is True, then Are_of_Same_Type(A, B) is also True. But Are_of_Same_Type(A, B) being true says nothing about Is_Descendant(A, B). I don't see any use of "equality" in the wording for Is_Descendant, either. So I think this is OK as is.
23.5.1:
[GB:] The result type of Nominal_Subtype, a "Subtype_View'Class" is not visible in this package. Use Asis.Subtype_Views.Subtype_View'Class instead.
23.5.2:
[GB:] The result type of Selector_Dclaration, a "View_Declaration'Class", is not visible in this package. Use Asis.Views.Declarative_Regions.View_Declaration'Class instead.
23.6.3:
[GB:] The result type of Result_Subtype, a "Subtype_View'Class", is not visible in this package. Use Asis.Subtype_Views.Subtype_View'Class instead.
23.6.4:
[GB:] The result type of Family_Index_Subtype, a "Subtype_View'Class", is not visible in this package. Use Asis.Subtype_Views.Subtype_View'Class instead.
23.6.5:
[GB:] The result type of Convention, a "Conventions", is not visible in this package. Use Asis.Views.Conventions instead.
23.7.2:
[GB:] The result types of Low_Bound and High_Bound, a "Object_View'Class", is not visible in this package. Use Asis.Object_Views.Object_View'Class instead.
23.7.5:
[GB:] The result types of Storage_Pool and Storage_Size, a "Object_View'Class", is not visible in this package. Use Asis.Object_Views.Object_View'Class instead.
23.7.6:
[GB:] The result type of Designated_Profile, a "Profile", is not visible in this package. Use Asis.Profiles.Profile instead.
23.8.1:
[GB:] (1) The result type of Discriminants, a "Declarative_Regions.Region_Part", is not visible in this package. Use Asis.Views.Declarative_Regions.Region_Part instead.
(2) Also, the result type of Nondiscriminant_Region_Parts, a "Declarative_Regions.Region_Part_List", is not vislble in this package. Use Asis.Views.Declarative_Regions.Region_Part_List instead.
(3) "Function Nondiscriminant_Region_Parts returns a list of Region_Parts, one for each separate visible region part, each comprising components, entries, and protected subprograms from a single list of components or items of subtype C."
That final part:
"from a single list of components or items of subtype C."
I have no idea whatsoever what that means. Until that part of the sentence thought I knew what it wanted. What single list?
[Randy:] We don't have a term or syntax for the particular thing that we're trying to name here. The point is that you get different regions for different lists of components or items. For instance, a protected type has two lists, so there are two regions (not one).
I'm slightly confused, though, wondering if separate variants of an individual type are in the same or different regions. This wording implies that they are different regions, but I would have expected them to be the same.
23.8.2:
[GB:] The result type of Index_Subtype, an "Elementary.Discrete_Subtype'Class", is not visible in this package. Use Asis.Subtype_Views.Elementary.Discrete_Subtype'Class instead.
23.9.2:
[GB:] The result type of Callable_Profile, a "Profile", is not visible in this package. Use Asis.Profiles.Profile instead.
23.9.4:
[GB:] An argument type of Primitive_On_Subtypes, a "Subtype_Vector'Class", is not visible in this package. Use Asis.Subtype_Views.Subtype_Vector'Class instead.
Similarly, the result type of Associated_Tagged_Type, a "Composite.Tagged_Subtype'Class", is not visible in this package. Use Asis.Subtype_Views.Composite.Tagged_Subtype'Class instead.
--
[GB:] Primitive_On_Subtypes returns what? The text says "Returns a vector of the subtypes on which the subprogram C is primitive."
Across what domain? There could be subtypes declared in any number of compilation units all of which have some particular subroutine as a primitive. Even saying something such as "all of the subtypes visible at the point of the calling reference" implies doing a great deal of searching and trying to duplicate the compiler's implementation of visibility.
I doubt that this routine can be implemented.
Even if it can be implemented it would be a great deal of work. The compiler has no reason to record such information so any ASIS implementation would be forced to reimplement the visibility rules for Ada. I don't see that happening.
[Randy:] Gary is very confused about primitiveness, or what a callable view is, or something. A subprogram is primitive if and only if it is declared in the same declaration list as the subtype (see ARM 3.2.3). It has nothing to do with visibility. It might be inherited, but again in the same unit as the subtype.
A callable view is a view of something that can be called; each view is going to denote a particular subprogram (I'm assuming that this only works on a successfully compiled program, otherwise I'd expect ASIS_Failed or another exception to be raised).
So to implement this (in the worst case where the information is not stored), look up the subprogram in the symboltable; for each parameter type and the result type, see if the associated type is declared in the same scope, and if so, it is primitive, and if not, it isn't. Note that this is a property of the type, not any subtype, so the searching is limited by the number of parameters and the size of the scope.
So it seems implementable (not trivial, but possible), and it is very important when figuring out what is going with derived types.
--
[GB:] Associated_Tagged_Type undefined and/or redundant.
"Returns the controlling tagged type of a dispatching operation C."
The Ada standard does not contain the phrase "controlling tagged type". ASIS is not supposed to invent new terminology. It should not do so here.
For a dispatching call, at runtime there will be a controlling tag value and that tag value is associated with some particular tagged type. However that is a runtime consideration and cannot always be predicted by the compiler and certainly not by ASIS. ASIS works with, at best, the semantic leavings of the compiler. If the compiler didn't know the information, or if the information was only known to some transient optimization phase, then ASIS won't know the information.
What can be done is to determine what subroutine specification declaration corresponds to the called subprogram. However that functionality already exists in ASIS as the Corresponding_Name_Declaration interface in ASIS.Expressions. So there would be no purpose to duplicating that functionality in Asis.Views. Eliminate the interface or add text explaining what the interface is actually expected to do that is different than the existing interface.
[Randy:] The term "controlling type" is defined, but only for formal abstract subprograms. So we ought to be saying something else here. This appears to be asking for the (unique) tagged type for which this subprogram is primitive. The function is (slightly) redundant with Primitive_On_Subtypes, but this one doesn't need a list, so it is more convinient. So a wording fix is needed.
23.9.5:
[GB:] (1) The result type of Prefix_Object, a "Object_View'Class", is not visble in this package. Use Asis.Object_Views.Object_View'Class instead.
(2) Unprefixed_Callable_View not useful. What use is this interface? And what does "returns the standard (unprefixed) form callable_view of C" mean?
Other than by calling Is_Prefixed_View(C), is there any way for a program to tell the difference between the prefixed Callable_View and the artificial (and probably simulated (Is_Part_Of_Implicit)) unprefixed Callable_View?
It is possible to ask for the Callable_Profile associated with a Callable_View but that simply returns a Profile object. Profile objects are almost useless but it is possible to use them to ask about the declaration of the interface being called. That information would be identical for both the prefixed and the unprefixed callable so again, what use is this interface?
[Randy:] Actually, this is a misunderstanding of how Ada prefixed calls work. The profile of an prefixed call does not include the first parameter of the call; this function retrieves the entire profile (including the first parameter). (You can see that a prefixed call has a different profile by renaming it.) One could use the profile to find out the subtype information for the first formal parameter (can't get that from the prefixed profile). So there is a use for this function.
23.9.6:
[GB:] The result type of Access_To_Subprogram_Value, a "Object_View'Class", is not visble in this package. Use Asis.Object_Views.Object_View'Class instead.
23.10.2:
[GB:] The result type of Designated_Subprogram, a "Callable_View'Class", is not visible in this package. Use Asis.Callable_Views.Callable_View'Class instead.
23.11.8:
[GB:] The result types of Visible_Part and Private_part, a "Declarative_Regions.Region_Part" is not visible in this package. Use Asis.Views.Declarative_Regions.Region_Part instead.
23.12.2:
[GB:] The result type of Generic_Formal_Part, a "Declarative_Regions.Region_Part", is not visible in this package. Use Asis.Views.Declarative_Regions.Region_Part instead.
23.12.4:
[GB:] The result type of Current_Package_Instance, a "Package_Views.Package_View'Class", is not visible in this package. Use Asis.Package_Views.Package_View'Class instead.
23.12.6:
[GB:] The result type of Current_Subprogram_Instance, a "Callable_Views.Callable_View'Class", is not visible in this package. Use Asis.Callable_Views.Callable_View'Class instead.
23.14:
[GB:] There are a small number of interfaces and types that deal with Statement_View. None of them create a Statement_View value. There is no interface in the draft that can be used to create a Statement_View. Therefore all mention of Statement_View and all interfaces and types utilizing Statement_View should be eliminated.
[Randy:] Statement_View is used for block and loop labels, and goto labels. You would get one by converting an element representing a name of a label into a View (using Asis.Expressions.Corresponding_View, since an Ada Name is an ASIS expression).
Tucker is supposed to be improving the wording to make this clear (as part of SI-54); hopefully that will clarify the situation.
23.15.1:
[GB:] 23.2.5 and 23.15.1 are in direct contradiction to each other.
In 23.2.5 it says "If a declaration defines multiple views because the list of identifiers has more than one element, then a separate View_Declaration is associated with each view,just as though they were defined by separate declarations."
Then in 23.15.1 it says for Corresponding_View_Declaration that "Declaration specifies the declaration to query. Returns a view that specifies the entity denoted by Declaration."
One of these is wrong and needs to return plural instead of singular.
Either (a) 23.2.5 is wrong, which would imply that View_Defining_Name needs to return an Asis.Defining_Name_LIST, or (b) 23.15.1 is wrong, which would imply that Corresponding_View_Declaration needs to return a View_Declaration_LIST.
[Randy:] I think 23.15.1 is wrong. I suspect that changing 23.2.5 would cause other messes (we don't want multiple declarations in the Semantic Subsystem).
I think the fix Gary suggests to 23.15.1 is necessary.
----------------------------------------
!appendix

From: Bill Thomas
Sent: Wednesday, November 4, 2009  2:03 PM

Another little 7 page update from Gary on the semantic interface. Probably too
late for the agenda, but I want to keep you informed on his review.

****************************************************************

From: Gary E Barnes
Sent: Thursday, February 11, 2010  5:06 PM

Section 23 - Remove all of it.  The design as presented in the draft is
seriously underspecified to the point where it cannot be implemented and
could not be used just based on the descriptions and examples if someone
were to come up with a supposed implementation.

An alternative of course would be to rewrite the text of the section from
scratch, putting in actual substantive information about the interfaces and
what the various functions are actually intended to do.

The present draft and the previous draft differ in that the new draft adds
three or four new functions, adds an about equal number of sentences, and
modifies a phrase or three.  It is unfortunately not materially more
informative than the previous draft.

My stance is remove the entire thing.  It does not represent a complete
design and it not remotely implementable as it stands.  I'm not really
interested in trying to "fix" it.  I think the design as presented is far
too preliminary for anyone to be able to guess the intentions of the
designer(s).

As a second stance on the subject of Section 23, I also think that this
section would require a very great deal of effort to implement.  Perhaps as
much as that required by all of the rest of ASIS.  It wants a great many
things that, while a compiler may construct some of them in its head, such
as private package views, there is no utility in recording those things in
program libraries (or .ali files or ...) and so ASIS would have to recreate
them from first principles leading to much effort and quite likely producing
results that differ from that of the compiler (i.e. bugs).

****************************************************************

From: Gary E Barnes
Sent: Thursday, February 11, 2010  7:23 PM

[Part of a private e-mail thread - Editor.]

Ah...  It was a small but highly frustrated gripe...with Section 23.  Total
mess.  I sat down one day and tried to start doing a trial implementation.  I
couldn't even get started.  The things I thought I probably understood were way
way way too much work (all of those views based on language-theory views defined
in the Ada Standard that do not exist except in the transient mind of the
running compiler and maybe not even there, at least not explicitly).  And the
rest of it was just a mystery.  I think it asks for things I simply don't have
available to report.  Trying to recreate them involves creating what amounts to
a new (partial? full?) Ada compiler.

I've already got an ASIS'05 implementation modulo Section 23.  All set to go.
Even passes all of my tests (several thousand) all the way back to Ada'83 code.
I wrote a bunch of new ones doing twisty things with interfaces and all of that.
Discovered a number of things about Ada'05 that I didn't know existed (and I
still don't know why some of them exist...8^)...but they can be traversed and
have the right semantic results).

Back with ASIS'83 I spent quite a few months duplicating what the compiler does
internally with expanded generics.  The compiler has no reason to record
expanded generics in the program library, and doesn't.  So I have to fake it.
Being able to traverse generic instances was something I personally considered
to be important and definitely useful.  It is complete with all of the Ada'95
complications of child generics and generics inside other generics referring to
(parent) generics found inside still other generics.  Yuck.  It forms an N
dimensional dependency lattice.  Fortunately a sparse lattice.

Section 23 seems at first blush to be even more work than that, and certainly
harder to figure out.  Generics were "simple but tedious" in that testing was
simple.  Traverse an example, print it out as a tree, and you either see
everything you expected to see or you didn't.  Views are harder given that, not
being even a part-time Ada language lawyer, I can only make an educated layman's
guesses about what should or should not be visible in any number of situations.
The only way to check a test is to look for every nit and make sure none are
missing and none are extra.  Hard when you don't know all the nits.

In its present form, I have to say that I will never ship an ASIS Semantic
Subsystem.  I simply can't figure out what much of it is supposed to do.  The
rest is somewhat mind boggling in sheer size.  If I can't understand it then I
can't implement it.

Please let me know what happens to Section 23 in the meeting.  I'll probably
never find out otherwise.

****************************************************************

From: Randy Brukardt
Sent: Friday, February 19, 2010  11:37 PM

My first reaction to this was gee, join the club when it comes to implementation
difficulty. What ASIS demands is so different from what Janus/Ada does
internally, it would be hard to provide more than 20% of ASIS from the our
compiler. I think the only way to implement ASIS for Janus/Ada would be to build
an entirely dedicated front end that creates ASIS trees, and then try to match
that up with the compiler-generated semantics. Not fun and hard to say if it
would even work. Needless to say, I never started on an ASIS implementation.

Anyway, that isn't productive. I would expect Section 23 to be a major
implementation effort; it's providing a whole lot of semantic information that
is currently very difficult to impossible to figure out in ASIS. But obviously
it can't be so arcane that it isn't implementable at all.

So the question is what needs to happen to make this more implementable (without
losing the needed capabilities).

Here's where my areas of concern are. I'm not particularly worried about the
missing definitions, because those will certainly get filled in before the thing
is done, and Tucker typically does a good job on such things. I'm more worried
about cases where the correct answer isn't obvious.

One problem that Tucker supposed to be working on is some description of what
happens for renames. The question was asked what the result of Is_Component(A)
when A is defined as:
     A : Natural renames B.C;
This looks like a sure-fire sucking mudpit, as the best answer seems to vary
from routine to routine.

More generally, I've been worried about implementing view-specific queries.
Compilers that I'm aware of (including ours) modify the symboltable as the
compilation progresses. The symboltable information available to ASIS about a
compilation reflects the state at a particular point of the compilation (usually
the end of the unit). Querying that and getting the right answer when visibility
changes all the time would be difficult; indeed we tried to do something like
that for stubs back in the day, and eventually gave up and simply took a
symboltable snapshot at the point of the stub. When means that getting
visibility right for views probably would require such snapshots at the end of
every scope where a view could be created -- not a very pleasant sounding
suggestion.

I'm also concerned about being able to get back to elements: very little of the
information in our symboltable has any source location information. (That's a
result of getting the compiler to work on CP/M and MS-DOS: can't put
nice-to-haves into a 48K Max symboltable.)

I'm wondering if these are similar to your implementation concerns, or if
something else was the root of the trouble.

Unfortunately, I can't think of a real alternative to the view-based model. The
characteristics that we want to be able to query are visibility-based. Heck,
pretty much everything interesting in Ada is visibility-based! Completely
ignoring visibility won't given the information needed.

Perhaps it would be good to go back and recall why we felt this subsystem was
necessary in the first place. We noticed that almost all existing ASIS
applications do program transformations (this is why we got rid of most of the
allowed variations; program transformations don't work if the original source is
obscured); hardly any do anything semantic in nature. Jean-Pierre Rosen (who is
an ARG member and also has an significant ASIS application) told us that was
because it is very hard to do anything much with the ASIS information. He told
us that he had a 800 line (I may be misremembering the number, but it is a lot)
routine to figure out if a type is limited or not. In explaining it to the
group, we found a bug -- it didn't even get the right answer all of the time.
But of course the underlying Ada compiler knows that information - it should be
possible to query it. Similarly, the ASIS semantic queries that return type
information have a nasty tendency to return NIL when there isn't an easy answer.
For instance, T'Class always returns NIL. Programs have to have alternative ways
to do analysis in such cases, and that makes a combinational explosion.

So we decided that it was better to have a way to get truly semantic information
from the compiler. It shouldn't have any problem determining if a type is
limited (or class-wide or whatever). The probkem is, however, that that
information is view-dependent. A type can be limited in some views and
non-limited in other views (imagine a limited private type completed with an
integer, for instance). And that goes for all interesting type characteristics.

I'm thinking that the purely view-based model has too much detail. After all,
under most circumstances, there are only a couple distinct views of a type.
Perhaps we should just concentrate on the characterists of each of those main
views.

The problem with that, of course, is that it means the ASIS information might
vary a bit from the compiler's in unusual circumstances (those insane programs
where characteristics and subprograms are inherited in package bodies are an
example). It might be worse to have information that is slightly wrong than to
not have it at all (you'd hate to have a security-checking tool to miss a
vulnrability because of some shortcut in ASIS).

In any case, ASIS is supposed to stand for Ada SEMANTIC Interface System -- it
would be nice if it actually provided useful semantic information beyond that
fairly trivial. You don't need a fancy library to do syntactic analysis -- the
big benefit of something like ASIS is in the semantic information, and
especially in the type information.

Anyway, your thoughts would be appreciated.

****************************************************************

From: Gary E Barnes
Sent: Tuesday, February 23, 2010  5:12 PM

> Anyway, that isn't productive. I would expect Section 23 to be a major
> implementation effort; it's providing a whole lot of semantic information
> that is currently very difficult to impossible to figure out in ASIS. But
> obviously it can't be so arcane that it isn't implementable at all.

A word here, ASIS'83 was designed and constrained by a particular mind set.  A
mind set that is probably still pertinent.

a) Users want.
b) Compilers do not have.
c) ASIS is a scavenger.
d) Tails don't wag dogs.
e) KISS

Expanded:

a) Users want.  Users wanted information.  In particular they wanted information
   that "the compiler must know" so they "just wanted access to that
   information".

b) Compilers do not have.  Compilers often don't have that information either,
   perhaps because they don't necessarily need it (an example would be a call
   graph for a compiler with optimization turned off).  And compilers very often
   don't record everything they might have transiently known at some point
   during a compilation.

c) ASIS is a scavenger.  Think recycling.  ASIS is intended to be a back-door
   into information that the compiler leaves behind, because the last thing a
   vendor wants is two compilers that can never be kept totally in sync and
   because the last thing a user wants is an ASIS that gives different answers
   than the compiler would give.

d) Tails don't wag dogs.  ASIS is the tip of a tail on a large dog.  Tail tips
   that bother the dog too much tend to get bitten off.

e) KISS.  A complicated implementation means (a) no two implementations will
   ever agree and (b) most implementations won't even be attempted.  KISS ==
   ASIS might actually get implemented by a vendor.

...
> One problem that Tucker supposed to be working on is some description of
> what happens for renames. The question was asked what the result of
> Is_Component(A) when A is defined as:
>      A : Natural renames B.C;
> This looks like a sure-fire sucking mudpit, as the best answer seems to vary
> from routine to routine.

Queries where the correct answer is not obvious are probably queries that should
not exist, or should exist in multiple forms, but probably should not exist.
Not obvious == vague question == nobody will ever be happy.

> More generally, I've been worried about implementing view-specific queries.
> Compilers that I'm aware of (including ours) modify the symboltable as the
> compilation progresses. The symboltable information available to ASIS about

Stop right there.  There is no basis to assume that there is *any* symbol table
information available to ASIS.  Very bad, very incorrect, assumption.  My ASIS
has exactly zero symbol table information available.  What I have is a tree
where nodes of the tree that represent a reference to something contain a
pointer to that something.  That's it.  No symbol table.  What I have is the
*result* of the compiler doing symbol table lookups.  I don't have the table.  I
don't have the mechanism for doing lookups in the table that I don't have.  All
such symbol tables cease to exist once the compiler stops contemplating the
particular context that required their particular existence.

> a compilation reflects the state at a particular point of the compilation
> (usually the end of the unit). Querying that and getting the right answer
> when visibility changes all the time would be difficult; indeed we tried to
> do something like that for stubs back in the day, and eventually gave up and
> simply took a symboltable snapshot at the point of the stub. When means that
> getting visibility right for views probably would require such snapshots at
> the end of every scope where a view could be created -- not a very pleasant
> sounding suggestion.
>
> I'm also concerned about being able to get back to elements: very little of
> the information in our symboltable has any source location information.
> (That's a result of getting the compiler to work on CP/M and MS-DOS: can't
> put nice-to-haves into a 48K Max symboltable.)

That sort of situation is exactly why ASIS has so many implementation
permissions and application advisories.  ASIS can only report either (a) what
information it finds lying around or (b) what information it might be able to
recreate without the help of the compiler.

> I'm wondering if these are similar to your implementation concerns, or if
> something else was the root of the trouble.

That's basically it.  The subsystem requires me to know things that, not only do
I not know, but they are things that the compiler may or may not have bothered
to know, and the compiler certainly did not record them anywhere if it did know
them.  So my ASIS has no prayer unless those things can be reconstructed based
on what I do know, and that reconstruction looks to be more work than all of the
ASIS 83+95+05 work I've had to do to date.  There is also the niggling little
fact that I probably won't get it 100% correct and there is no way for me to
even check my work (no ACVCs or ACAT tests).

> Unfortunately, I can't think of a real alternative to the view-based model.
> The characteristics that we want to be able to query are visibility-based.
> Heck, pretty much everything interesting in Ada is visibility-based!

There speaks I think the language lawyer.  Is there really a user community that
would want to ask those very Ada-Standard legalese sorts of questions?  It can
be vital for a lawyer to know where a comma is placed and what that placement
implies, but most more reality based folks won't even see why a comma should be
placed.

If there is such a community then I'll take your word for it, but is there?  And
are the questions represented by this subsystem actually a set of questions
being made by that community?  ASIS is historically a tool for dissecting
compiled Ada programs rather than a tool for compiling them or deciding whether
they could be compiled.  So it answers questions of the sort "What did the
compiler decide?" rather than "What would a compiler decide?" or "Why did the
compiler decide?"  So I want to ask "Do we really need to go there?"

> Completely ignoring visibility won't given the information needed.
>
> Perhaps it would be good to go back and recall why we felt this subsystem
> was necessary in the first place. We noticed that almost all existing ASIS
> applications do program transformations

Interesting.  I on the other hand know only one ASIS application that performs
any sort of program transformations and it only puts in what amounts to Aspect
changes (in effect all it does it insert a line here or there and doesn't really
"transform" anything in any meaningful sense).  Program transformations, as
opposed to analysis of various sorts, was not part of the target application
space back in ASIS'83 days.

> (this is why we got rid of most of
> the allowed variations; program transformations don't work if the original
> source is obscured); hardly any do anything semantic in nature. Jean-Pierre
> Rosen (who is an ARG member and also has an significant ASIS application)
> told us that was because it is very hard to do anything much with the ASIS
> information. He told us that he had a 800 line (I may be misremembering the
> number, but it is a lot) routine to figure out if a type is limited or not.
> In explaining it to the group, we found a bug -- it didn't even get the
> right answer all of the time. But of course the underlying Ada compiler
> knows that information - it should be possible to query it.

Change query to record-and-query.  Even that is chancy.  There is "know" in the
sense that there is a bit somewhere that could be recorded and later examined,
and then there is "know" in the sense that the compiler may have different
analysis paths with different sets of code in each path based on different
preconditions (preconditions like "assume this type is limited").  A bit might
get recordable somewhere, and so be queryable, but the other situation would not
be recorded and no query is possible.

> Similarly, the
> ASIS semantic queries that return type information have a nasty tendency to
> return NIL when there isn't an easy answer.
>
> For instance, T'Class always
> returns NIL. Programs have to have alternative ways to do analysis in such
> cases, and that makes a combinational explosion.

They return Nil when there is no answer.  Easy had little to do with it, at
least back in ASIS'83.  We often went to great lengths to specify non-Nil
returns, intending Nil to be used only when there was no other reasonable
answer.  "reasonable" being highly influence by perceived implementation effort.

But T'Class is a good example.  It refers to an abstract idea within the Ada
language that has no concrete realization.  Back in the ASIS'83 days, had the
T'Class concept existed it would have been treated just like all of the other
implicit elements that crop up in Ada.  There would have been some fake set of
implicit elements defined to give it a physical Element representation.  It
would have been like the builtin primitive operations for types.  Just as there
is a fake implicit declaration of "=" for types, that some implementations might
not implement but which was defined down to every detail, there would have been
some sort of fake declaration for T'Class.

Unfortunately, just like in ASIS'05 where the ARG has arbitrarily decided to
remove all traces of implementation permissions, the ASIS'95 group decided
arbitrarily to just eliminate all discussions of the many many implicit
constructs required to keep ASIS from returning Nil in so many cases.  They even
went so far as to eliminate the permissions to implement many of them as well.

My ASIS implements all of the implicit constructs but that doesn't help someone
using one of the other implementations.

> So we decided that it was better to have a way to get truly semantic
> information from the compiler. It shouldn't have any problem determining if
> a type is limited (or class-wide or whatever). The problem is, however, that
> that information is view-dependent. A type can be limited in some views and
> non-limited in other views (imagine a limited private type completed with an
> integer, for instance). And that goes for all interesting type
> characteristics.

Remember (c) ASIS as scavenger, and (d) ASIS as tail of dog, above.  It doesn't
matter, not at all, whether or not the compiler, while it is running, is able to
make some determination or not.  What matters is whether it ever makes and
ultimately records that determination anywhere.  Either we have the case "no
information" == "no answer/Nil" or we have "no information" == "ASIS is a 2nd
compiler".  ASIS as a 2nd compiler is a nonstarter.  Some things can be easily
reconstructed, others take 800 lines of code and still aren't quite right.
Sometimes no answer is better than might be answer.

> I'm thinking that the purely view-based model has too much detail. After
> all, under most circumstances, there are only a couple distinct views of a
> type. Perhaps we should just concentrate on the characterists of each of
> those main views.
>
> The problem with that, of course, is that it means the ASIS information
> might vary a bit from the compiler's in unusual circumstances (those insane
> programs where characteristics and subprograms are inherited in package
> bodies are an example). It might be worse to have information that is
> slightly wrong than to not have it at all (you'd hate to have a
> security-checking tool to miss a vulnrability because of some shortcut in
> ASIS).
>
> In any case, ASIS is supposed to stand for Ada SEMANTIC Interface System --
> it would be nice if it actually provided useful semantic information beyond
> that fairly trivial. You don't need a fancy library to do syntactic analysis
> -- the big benefit of something like ASIS is in the semantic information,
> and especially in the type information.
>
> Anyway, your thoughts would be appreciated.

I'm thinking in terms of (c) and (d) of the ASIS'83 mind set.
(c) If the compiler didn't leave it behind for you to find then you won't get
    it.
(d) Compilers are dogs, ASIS libraries are tails, tails don't wag dogs.

"Views" of types and other objects, such as are found in the Ada Standard aren't
useful to debuggers or to other of the usual sorts of tools that are found in a
compiler's tool set.  So I would not expect that sort of information to be
present in any existing Ada environment implementation.

Take a look as ASIS'83 and ASIS'95.  All of the syntactic information, and all
of the semantic information (limited though it might be), is exactly the sort
information that debuggers, editors, cross referencers and suchlike tend to
need.  So it is perhaps not surprising that it was little problem (for Telesoft,
Rational, and GNAT back then) to agree that this information was both easy to
locate and easy to provide.  There were lots of queries proposed back then that
were shot down because none of the potential vendors had any way to provide the
answers without reengineering their compilers or their library systems.
Naturally any sort of serious reengineering was not even on anyone's table.

I think that Section 23 is very vague as it stands.  Also, noticeable parts of
what it wants to know about types, if answers are available at all, could be
obtained by simply adding new queries for existing Type_Defnition objects (e.g.
an Is_Limited query that asks the semantic question rather than the syntactic
question).  Rather than add a whole new set of packages and types, what is there
in here that can't be more simply solved by adding some queries on existing
Elements?

****************************************************************

From: Randy Brukardt
Sent: Wednesday, February 24, 2010  1:48 PM

I'm not going to discuss your note point-by-point, since it isn't going to be
productive. But a couple things stand out:

> I'm thinking in terms of (c) and (d) of the ASIS'83 mind set.
> (c) If the compiler didn't leave it behind for you to find then you won't get
> it.
> (d) Compilers are dogs, ASIS libraries are tails, tails don't wag dogs.

Point (c) here makes no sense whatsoever. The only information that a compiler
has to "leave behind" is some semantic information about specifications. (And
GNAT tries hard to minimize that.) For Janus/Ada, the only things "left behind"
are semantic information about package and generic package specifications, the
compiled object code, and the original source code. There isn't even a direct
connection between these artifacts. The compiler saves no information whatsoever
about bodies other than the compiled object code. So there isn't anything to
scavange from. (So far as I can tell, that is also true of GNAT.)

So, if you take these two points literally, ASIS could have no information about
bodies at all. Janus/Ada also uses universal code sharing, so there never is an
expansion of a generic body *anywhere*. The whole concept doesn't exist in the
compiler.

An ASIS which stuck to what the compiler has available would be pretty useless.
So it has to go beyond. Moreover, implementing a useful ASIS is going to (by
definition) require making changes to the compiler. (I've been told several
times that extensive changes were made to GNAT to record information needed by
ASIS.)

It seems obvious to me that ASIS and the Ada compiler have to be a cooperating
system. If not, you really end up writing a new Ada compiler just to implement
ASIS (because there is no sane reason for the compiler to save any body
information, with the exception of implementing stubs).

So these two principles don't make much sense to me.

> I think that Section 23 is very vague as it stands.  Also, noticeable
> parts of what it wants to know about types, if answers are available
> at all, could be obtained by simply adding new queries for existing
> Type_Defnition objects (e.g. an Is_Limited query that asks the
> semantic question rather than the syntactic question).  Rather than
> add a whole new set of packages and types, what is there in here that can't be
> more simply solved by adding some queries on existing Elements?

The problem is that we can't "fix" most of the existing queries because if their
requirements to return NIL in unfortunate cases (like T'Class). That would be
too incompatible at runtime. And ASIS doesn't usually create elements on the fly
(indeed, we thought that it never does that), so creating implicit elements when
needed didn't seem to fit the model. Perhaps ASIS '99 changed the model in a bad
way to prevent that sort of change. (We did add a requirement for implicit
dereference elements - which are obviously implicit - as that seemed pretty
necessary to do analysis).

Clearly, there also isn't enough built-in ASIS knowledge in our group. We were
given the standard to update when the supposed ASIS working group made no
progress at all in two years and then essentially disbanded. It's not something
we really wanted to do.

****************************************************************

From: Gary E Barnes
Sent: Wednesday, February 24, 2010  3:25 PM

> Point (c) here makes no sense whatsoever. The only information that a
> compiler has to "leave behind" is some semantic information about

ASIS'83 wasn't based on what compilers have to leave behind.  It was based on
what compilers of the time *did* leave behind.  GNAT was the only participant
that didn't have some sort of persistent information and the GNAT rep(s) of the
time thought they'd be able to do things on the fly but eventually came up with
some sort of optional tree files that the compiler could generate to speed
things up.

> So, if you take these two points literally, ASIS could have no information
> about bodies at all. Janus/Ada also uses universal code sharing, so there
> never is an expansion of a generic body *anywhere*. The whole concept
> doesn't exist in the compiler.

The compilers of the time all had *some* information and all of those "may
return Nil" clauses in the function descriptions reflected all of the known
cases of "but we don't have *that* information".

> An ASIS which stuck to what the compiler has available would be pretty
> useless. So it has to go beyond. Moreover, implementing a useful ASIS is

That depends on the compiler, what it leaves behind, and what you want to do.
ASIS'83, and even ASIS'95, did a very nice job of covering what folks wanted to
do *then*.  We have products used by paying customers that are based on those
ASIS variants.  *Now* however may very well be a different story.  I don't think
automatic program transformation as a subject area even existed back
then---other than turning routine bodies into is-separates and trivial things
like that.  Java, not to mention its various common code transformation
patterns, hadn't even been invented yet.

> going to (by definition) require making changes to the compiler. (I've been
> told several times that extensive changes were made to GNAT to record
> information needed by ASIS.)

As I said before I got lucky, but, other than getting Pascal to add a boolean or
two so that I could tell whether a routine ended with "end;" versus "end Name;",
we didn't have to make any changes to our compiler.  I did have to do a bunch of
work on generic instantiations but the compiler already recorded expansions of
first level instantiations (instantiations that the user actually typed in)
present and available.  I only had to fake instantiations that occurred inside
of other instantiations, so I had a model to copy and while tedious it was
fairly easy to navigate the problem.  As I recall, the Telesoft compiler kept
the complete generic expansion in its persistent data, or that was my impression
at the time, it was their idea in the first place.

> It seems obvious to me that ASIS and the Ada compiler have to be a
> cooperating system. If not, you really end up writing a new Ada compiler
> just to implement ASIS (because there is no sane reason for the compiler to
> save any body information, with the exception of implementing stubs).

There are sane reasons.  Apex saves lots of information because it tries very hard to do incremental recompilation and it goes so far as to merge new and old Diana/parse trees and reanalyzes just the new pieces.  But compilers vary, Apex made ASIS relative
ly easy and by producing lots of fake elements in the hazier bits of Ada semantics Apex ASIS managed to do everything.

> So these two principles don't make much sense to me.

Old saw: Ya had ta be there.  8^)

> > I think that Section 23 is very vague as it stands.  Also, noticeable parts of what
> > it wants to know about types, if answers are available at all, could be obtained by
> > simply adding new queries for existing Type_Defnition objects (e.g. an Is_Limited
> > query that asks the semantic question rather than the syntactic question). Rather
> > than add a whole new set of packages and types, what is there in here that can't be
> > more simply solved by adding some queries on existing Elements?
>
> The problem is that we can't "fix" most of the existing queries because if
> their requirements to return NIL in unfortunate cases (like T'Class). That

I wasn't thinking of fixing queries, rather I was thinking of adding queries.
There would be a new query, Is_Limited_Somehow() or something like that, which
would ask the new-to-ASIS question of 'Is this type, or any subcomponent of this
type, a limited type?"  This wouldn't solve all of the queries in Section 23 but
it should work for most of the Is_* queries on types.  It still leaves the
question of whether the information is there to be had.

> would be too incompatible at runtime. And ASIS doesn't usually create
> elements on the fly (indeed, we thought that it never does that), so

ASIS'95 pretty much banned fake elements.  I never knew why.  ASIS'83 had an
array of fake elements.  You mentioned Foo'First in other mail, in ASIS'83
'First is an implicit (fake) primitive subroutine for appropriate types.  Pretty
much every "identifier" that could be found in the Ada'83 BNF had a defined real
or fake declaration that could be found and had a defined parent element and all
the rest.  None of it was all that hard to do but there were times when I
thought the discovery of new fakes would never end.

So 'First was a reference to a fake function declaration, "function 'First
return Standard.*Universal_Integer*;" and "type *Universal_Integer*;" was
another of the predefined fakes.  'First had a parent which was the defining
type---just like "=" and the other more normal primitives.  No Nil would show up
until you tried to get the Corresponding_Body_Declaration and applications would
be prepared for that simply because most external library routines will tend to
not have bodies.  We even had implicit fakes for the implied automatic
conversion for attributes that return universals but auto-convert into whatever
type is required.  We tried to cover every hole we could find in the language
(all the places where there was implicit "magic" applied by a compiler).

(I still have all the email if you have nothing to do but read old email for a
month or so... 8^))

> Clearly, there also isn't enough built-in ASIS knowledge in our group. We
> were given the standard to update when the supposed ASIS working group made
> no progress at all in two years and then essentially disbanded. It's not
> something we really wanted to do.

Hmmm, that lack of progress may have been a clue, sad to say.  I've done five
differing ASIS implementations at this point (ASIS'83, Rational's ASIS'83+95
hybrid, ASIS'95, Rational's ASIS'95+05 hybrid, and now ASIS'05) so I have a
rather large investment in ASIS, but if nobody is bothering to attend the
meetings, and nobody is bothering to ask questions, then maybe nobody is left
that is really interested.

I know we have customers that use ASIS---we get questions and such on
occasion---had one yesterday in fact.  But nobody has been barking up my
particular tree about wanting any new ASIS gizmos (such as Section 23).  That
may reflect the audience, ours is essentially all industry, GNAT has a big chunk
of academia plus industry, and I'm afraid I don't know much about Janus/Ada or
others.  GNAT users may have more ambitious ideas of what they want out of ASIS
than our users do.

****************************************************************


Questions? Ask the ACAA Technical Agent