Version 1.4 of si99s/si99-0047-1.txt
!standard 1.1 09-05-06 SI99-0047-1/03
!class binding interpretation 09-03-11
!status work item 09-03-11
!status received 09-03-11
!priority Medium
!difficulty Easy
!qualifier Error
!subject Editorial Review Corrections
!summary
Make changes in the Standard identified via editorial review.
!question
Should we make the changes recommended during the ARG review of the standard? (Yes.)
!recommendation
(See Summary.)
!wording
Introduction:
Delete "CASE" from the first paragraph.
[CASE is an archaic term, and this is a general introduction anyway. Suggested by Randy.]
Delete "debuggers, " from the Second paragraph, and replace "reformators" by "reformatters".
[D.3.1 says that ASIS specifically was not designed to support debuggers. So why is
it in this list?? - suggested by Greg. Ed says that "reformators" has something to do "with Luther,
Calvin, and their buddies".]
Delete the third paragraph.
[This is text directly copied from the ISO drafting standards. It might make sense to mention
it somewhere, but surely not in an introduction. It has been added as an AASIS discussion item
in clause 1.3. Suggested by Randy.]
Replace the rest of the clause with:
The ASIS interface consists of a set of types, subtypes, and subprograms which provide a capability
to query the Ada compilation environment for syntactic and semantic information. The ASIS interface
can be separated into two related subsystems, the syntactic subsystem and the semantic subsystem.
The syntactic subsystem provides the ability to traverse a program based on the syntactic (textual)
structure of the program, while the semantic subsystem provides the ability to traverse the program
based on the semantics (meaning) of the program. Interconnections are provided to allow moving
seamlessly between the subsystems.
package Asis is the root of the ASIS interface. It contains common types used throughout the ASIS
interface. all ASIS subprogram interfaces are provided using child packages. some child packages also
contain type and subtype interfaces local to the child package. The various child packages of ASIS
provide queries about the properties of the entities and other elements that make up an Ada program.
Queries are provided to learn about declarations, expressions, statements, compilation units, and so on.
Important common abstractions in the syntactic subsystem include Context, Element, and Compilation_Unit.
The type Context helps identify the compilation units considered to be analyzable as part of the Ada
compilation environment. The type Element is an abstraction of entities within a logical Ada syntax tree.
The type Compilation_Unit is an abstraction for Ada compilation units. In addition, there are
two sets of enumeration types covering various kinds of elements and units, such as Expression_Kinds.
The element kinds Element Kinds are a set of enumeration types providing a mapping to the Ada syntax.
The unit kinds Unit Kinds are a set of enumeration types describing the various kinds of compilation units.
A semantic entity in the semantic subsystem is represented by a View. Views can represent semantic concepts
like Units, Objects, or Statements, whether or not they exist explicitly in the analyzed program. Queries
are then provided to further decompose or traverse these views to other related views of the meaning of
the program text. In addition, there is a set of child packages that provide routines to transition back and
forth between the original syntactic element and the semantic view to obtain these different perspectives
on program meaning or content.
[The original text was far too detailed to include in an introduction. Moreover, all of this information
is repeated in clause 2.3 (a far more reasonable place). Suggested by Randy.
John suggested rewriting parts of the fourth paragraph to avoids confusion about Element Kinds (a set
of types) vs. Element_Kinds (a particular type).
Tucker suggested adding some text about the semantic subsystem (which was in an earlier draft of the
changes portion), which forced wholesale rearranging of the text.]
1.1:
Delete "CASE" from the first paragraph.
[CASE is an archaic term, and this is a general introduction anyway. Suggested by Randy.]
Delete "debuggers, " from the Second paragraph, and replace "reformators" by "reformatters".
[D.3.1 says that ASIS specifically was not designed to support debuggers. So why is
it in this list?? - suggested by Randy (after Greg). Ed says that "reformators" has something
to do "with Luther, Calvin, and their buddies".]
This International Standard is applicable to tools and applications needing syntactic and
semantic information [in]{from} the Ada compilation environment.
[Suggested by Greg; an ASIS application doesn't get to change the environment, so it is
a one-way change.]
1.1.2:
Replace the first sentence by:
This International Standard contains twenty-three sections and six annexes.
[Wrong count of annexes, wrong name for "sections" - suggested by Randy.]
Replace "Clause" by "Section" throughout (clauses have dots in their name), except
in the name of the package Asis.Clauses.
[Wrong name for sections, mentioned by Greg in passing, suggested by Randy.]
Replace "Section 23 Asis.Data_Decomposition.Portable_Transfer" with
"Section 23 package Asis.Views,
Asis.Program_Units,
Asis.Subtype_Views,
Asis.Subtype_Views.Elementary,
Asis.Subtype_Views.Composite,
Asis.Object_Views,
Asis.Object_Views.Access_Views,
Asis.Profiles,
Asis.Callable_Views,
Asis.Package_Views,
Asis.Generic_Views,
Asis.Exception_Views,
Asis.Statement_Views,
Asis.Declarations.Views,
Asis.Definitions.Views, and
Asis.Expressions.Views"
[Suggested by Greg.]
1.1.3.3:
Delete the last two sentences of the first paragraph:
[This clause is talking about ASIS implementations, not applications.]
1.1.3.4:
Add to the end of the first paragraph:
In any case, an application that accesses an Ada environment directly (other
than through ASIS or an extension) is not considered to be a conformant
application. All Conforming Applications fall within one of the categories
defined below.
[Moved the sentences deleted from the previous clause here, and generalized
them to make more sense.]
1.1.4 and its subclauses:
Delete all of these.
[They are not appropriate for the Standard; suggested by Greg and vetted
via the ARG mailing list - see !appendix.]
1.1.5:
Replace the entire list of exception by:
ASIS defines a set of global exceptions. These exceptions are raised
under the circumstances described in Section 5, package Asis.Exceptions.
[This list completely duplicates the information given in Section 5, just has less
detail. That adds nothing to the Standard except size, and offers the chance for
a maintenance errors (indeed, SI-24 added two exceptions to Section 5 but not here.)
- suggested by Randy.]
2.1.2:
Replace the first paragraph by:
The mechanisms for creating an environment and for adding and
replacing compilation units within an environment are
implementation-defined. In some implementations, environments are
represented by a persistent database, while in others they are not.
Consequently, ASIS requires the user of the interface (i.e., ASIS
application) to establish the compilation environment. This is done
through the context.
[The first paragraph of a clause shouldn't start with "however"! Replacement suggested
by Tucker.]
Modify the second paragraph:
The context {is a view of an Ada environment, and} defines a set of
compilation units and configuration pragmas {to be} processed by an
ASIS application. ASIS provides any information from a context by
treating this set as if its elements make up an environment
declarative part [by modeling some view (most likely – one of the
views of the underlying Ada implementation) on the environment.
Context is a view of an Ada environment]. ASIS requires an
application to identify [that] {the} view of the environment {to be
provided by the context} using the procedure
Asis.Ada_Environments.Associate, as shown in Figure 3. ASIS may
process several different contexts at a time.
[Reduce awkwardness, suggested by Tucker.]
Modify the fourth paragraph:
To facilitate the use of context, implementations may support the
use of containers which are logical collections of ASIS compilation
units. For example, some containers can hold compilation units
[which include] {that declare} Ada predefined types; another
container can hold implementation-defined packages. Containers
provide an implementation-defined way of grouping the compilation
units accessible for an ASIS application through the ASIS queries.
[that/which screwup. Suggested by Tucker.]
2.2.1:
Modify the first paragraph:
Structural queries are those ASIS queries which provide the top-down decomposition
and reverse bottom-up composition of the compilation unit according to its syntax
structure. {Structural queries are the primary component of the syntactic subsystem,
and are only found in that subsystem.} These structural queries are further characterized as:
[Re-introduce the term "syntactic subsystem", originally introduced
in the Introduction. Suggested by Randy.]
2.2.2:
Modify the first paragraph:
{Semantic queries are those ASIS queries which express semantic
properties (that is, the meaning) of constructs in the compilation unit.}
Semantic queries {in the syntactic subsystem}[are those ASIS queries which] express
semantic properties of ASIS Elements in terms of other Elements. There are
three kinds of semantic queries in {the syntactic subsystem of }ASIS:
[Avoid saying untruths about semantic queries that belong to the semantic
subsystem. Originally suggested by Tucker, rewritten by Randy.]
Add at the end:
In addition, semantic queries are provided by the semantic subsystem
(see section 23) which defines a largely self-contained set of packages
defining the semantics of the program in terms of Views and Declarations
of various kinds of semantic entities, such as Objects and Subtypes.
The semantic subsystem is linked to the structural queries through
Element_Denoting_View, and from the structural queries through
Corresponding_View, Corresponding_Subtype_View, and
Corresponding_View_Declaration.
[Suggested by Tucker, edited by Randy.]
2.2.3:
Modify the first paragraph:
Both structural (syntactic) and semantic queries are facilitated
through the notion of ASIS elements and their kinds. Most ASIS
queries {(outside the Semantic Subsystem)} provide for the
processing of specific constructs {and lists thereof} with respect
to the Ada Standard [and the processing of their lists].
[Suggested by Tucker.]
2.2.3.1:
Modify the first paragraph:
The base object in ASIS is the Asis.Element. Element is a common
abstraction used to [denote the syntax] {represent syntactic
constructs} (both explicit and implicit) [of] {occurring within}
ASIS compilation units. Elements correspond to nodes of a
hierarchical tree representation of an Ada program. Most elements of
the tree have child elements. These children can appear as single
elements (possibly with children themselves) or as a list of
elements (also possibly with children). As an example, [think
of]{consider} an Ada object declaration having three sub-parts or
children:
[Suggested by Tucker.]
2.2.3.2:
Replace Object_Declaration_View with Object_Declaration_Subtype
consistently. Also, replace A_Type_Definition by
A_Subtype_Indication.
[Object_Declaration_View is obsolete. Suggested by Tucker.]
2.2.3.5:
Modify all of these paragraphs as follows:
References from one part of an Ada program to another can be
traversed with functions whose name begins with “Corresponding_”,
such as: Corresponding_Children, Corresponding_Declaration,
Corresponding_Body, {Corresponding_Expression_Type,}
Corresponding_Type_Declaration,
[Corresponding_Type, Corresponding_Body_Stub,]
Corresponding_Name_Definition, Corresponding_Name_Declaration,
[Corresponding_Loop_Exited, Corresponding_Entry,] etc. If an element
references another element, the user can traverse to the referenced
element with [this] {such a} function. A Nil_Element is returned if no
definition traversal is possible.
{The most fundamental such function is
Corresponding_Name_Definition. This function traverses from a Name
to the corresponding defining name, represented by an element of
kind A_Defining_Name. From this point a traversal using the
Enclosing_Element function can be used to arrive at the declaration
of the corresponding program entity. Corresponding_Name_Declaration
combines these two traversals into a single operation. Corresponding_Expression_Type
traverses from an Expression to the declaration of its type.} [A slightly
more precise statement of the operation of this function is that identifier
references point to identifier definitions. Traversal arrives at the
identifier definition where the Enclosing_Element function is used
to arrive at the complete element declaration.]
For example, the user can traverse to the [type declaration
referenced in an object declaration] {declaration of the type for an
object named in an expression} with the
Corresponding_Expression_Type function as shown in Figure 6. Figure
6 also depicts links using the semantic query
Corresponding_Name_Declaration. (Note: the thin lined-arrows depict
syntactic queries while the thick-lined arrows depict semantic
queries.)
[The orginal text, especially the second paragraph, doesn't make much
sense. Somehow Tucker figured out this replacement. The list of example
Corresponding_xxx is way too long, there is no need to name 3/4ths of
them, noted by Greg, fixed by Randy.]
2.3:
Modify the first paragraph:
Figure 7 depicts the package architecture for the ASIS interface
{(not including the semantic subsystem)}. A tool
or application using ASIS has visibility to the entire declarative
region of package Asis including all {desired} child packages. To
get a better understanding of how these packages are used, see the
examples in Annex B.
[The picture doesn't include the semantic subsystem. We really need a new
figure, especially to remove the obsolete stuff. But for now, we'll
use Tucker's suggestion.]
Modify the following bullets:
* Type Element is an abstraction of [entities] {constructs} within a
logical Ada syntax tree.
* Element Kinds are a set of enumeration types [providing a mapping
to the] {that characterize the constructs of} Ada syntax.
* Type Compilation_Unit is an abstraction [for] {that represents an}
Ada compilation unit[s].
[Suggested by Tucker]
Modify the Asis.Elements bullet:
... {The element kinds}[Element_Kinds, defined in package Asis{,} are
defined as {a set of} enumeration types describing the various kinds
of elements. ASIS offers a ...
[Noted by Tucker, worded by Randy after John's suggestion for the Introduction.]
Add a listing of the packages in the semantic subsystem:
Asis.Views - This child package provides the basis of the
semantic subsystem. A view represents a semantic entity in an Ada program,
whether or not the entity has a syntactic representation. This package
includes mechanisms for finding the associated element (if any).
Asis.Declarations.Views - This child package provides a path to move from a
syntactic declaration (an element) to a semantic one (a view).
Asis.Definitions.Views - This child package provides a path to move from a
syntactic definition (an element) to a semantic one (a view).
Asis.Expressions.Views - This child package provides a path to move from a
syntactic expression (an element, which can be a value or object) to a semantic
one (a view).
Asis.Program_Units - This child package provides a semantic representation
of program units, including ones that don't exist explicitly, like inherited
subprograms and entities declared by generic instances. It also provides
a set of queries on this semantic representation.
Asis.Subtype_Views - This child package provides queries on semantic views
of (all) subtypes.
Asis.Subtype_Views.Elementary - This child package provides queries specifically
for semantic views of elementary subtypes.
Asis.Subtype_Views.Composite - This child package provides queries specifically
for semantic views of composite subtypes.
Asis.Object_Views - This child package provides queries on semantic views
of values and objects.
Asis.Object_Views.Access_Views - This child package provides queries on
semantic views of values and objects of access types.
Asis.Profiles - This child package provides the definition of and queries
on subprogram profiles.
Asis.Callable_Views - This child package provides queries on semantic views
of entities that can be called (subprograms and entries).
Asis.Package_Views - This child package provides queries on semantic views
of packages units.
Asis.Generic_Views - This child package provides queries on semantic views
of generic units.
Asis.Exception_Views - This child package provides queries on semantic views
of exceptions.
Asis.Statement_Views - This child package provides queries on semantic views of
statements.
[Obviously needed. Bill Thomas is supposed to update this entire section, but
we don't want to leave this obvious information out. Created by Randy.]
2.4.1
Modify all but the first paragraph as follows:
An application using all {non-obsolescent} child packages includes the
following in its context clause:
{with} Asis, Asis.Errors, Asis.Compilation_Units,
Asis.Compilation_Units.Times, Asis.Compilation_Units.Relations,
Asis.Ada_Environments, Asis.Implementation, Asis.Exceptions,
Asis.Elements, Asis.Iterator, Asis.Declarations, Asis.Expressions,
Asis.Clauses, Asis.Definitions, Asis.Statements, Asis.Text,
Asis.Ids, Asis.Data_Decomposition[; and
Asis.Data_Decomposition.Portable_Transfer.]{, Asis.Views,
Asis.Program_Units, Asis.Subtype_Views, Asis.Subtype_Views.Elementary,
Asis.Subtype_Views.Composite, Asis.Object_Views, Asis.Object_Views.Access_Views,
Asis.Profiles, Asis.Callable_Views, Asis.Package_Views,
Asis.Generic_Views, Asis.Exception_Views, Asis.Statement_Views,
Asis.Declarations.Views, Asis.Definitions.Views, Asis.Expressions.Views;}
Only these packages should be referenced (withed) by
a {newly written }portable application. {Obsolescent packages should not be
used in new applications; other}[Other] packages, which may be present in
a specific ASIS implementation, are not part of this International Standard.
[Add the semantic subsystem, remove obsolescent packages, gave this the syntax of
a context clause. Noted by Tucker, done by Randy.]
2.4.3:
Modify the last non-code paragraph:
The ASIS application is almost complete. A main {sub}program is
needed [which] {that} contains the required sequencing of calls to
initialize the ASIS interface, name the Ada environment, access the
Ada environment, loop through all Compilation_Units in the ASIS
Context with the Find_Violations procedure, and [closing/releasing]
{to close/release} all ASIS resources. The Compilation_Units in the
Context are placed into the Unit_List. This is achieved with the
following main {sub}program, called My_Application.
[Suggested by Tucker.]
2.4.5.2:
Modify the first paragraph:
The following provides [some] general rules to identify processing
when some inconsistent subset of Compilation Units is processed
during semantic query processing. Processing of inconsistent unit
sets is [in] {to} a certain extent implementation-dependent;
{nevertheless,} the following {rules} [in general should] apply:
[Suggested by Tucker.]
3.1:
Change the clause title to:
subtypes ASIS_Integer, ASIS_Natural, and ASIS_Positive
Add the other integer subtypes here:
subtype ASIS_Natural is ASIS_Integer range 0 .. ASIS_Integer'Last;
subtype ASIS_Positive is ASIS_Integer range 1 .. ASIS_Integer'Last;
Replace the descriptive text by:
Numeric subtypes that allow each ASIS implementation to place constraints
on the lower and upper bounds of values. Whenever possible, the range of
subtype ASIS_Integer should meet or exceed -(2**31-1) .. 2**31-1.
[Suggested by Randy.]
3.2:
Delete this clause (moved to 3.1).
[No description; Suggested by Randy.]
3.3:
Delete this clause (moved to 3.1).
[No description; Suggested by Randy.]
3.5:
Modify the second and third paragraphs:
Defined by the implementation, an ASIS context is a way to identify
a set of Compilation Units to be processed by an ASIS application.
This may include things such as the pathname, search rules, etc.,
which are attributes of the Ada environment and consequently
become[s] part of the ASIS Context only because [it] {the context}
is a "view" of the Ada environment.
[Because the contents of the Ada environment are
(Ada-)implementation defined, the ASIS context may contain illegal
compilation units.] An ASIS Context is a handle to a set of
compilation units accessible by an ASIS application. {Because the
contents of the Ada environment are (Ada-)implementation defined,
the} [The] set of compilation units available from an ASIS context
may be inconsistent, and may contain illegal compilation units. The
contents are selected from the Ada environment [as defined by the
corresponding Ada Implementation] {in an implementation-defined
manner}. ASIS should allow multiple open contexts.
[Suggested by Tucker.]
Modify the sixth paragraph:
Some implementations might not need explicit Name and/or Parameters
values to identify their Ada environment. Other implementations
might choose to implement the Ada environment as a single external
file in which case the name and parameters values might simply
supply the Name, Form, and any other values needed to open such a
file. Context shall be an undiscriminated limited private {type}.
[Suggested by Tucker.]
Add a new paragraph at the end:
A default-initialized context object is unassociated and not
open (see 8.4). Nil_Context represents no context, and is unassociated
and not open.
[Specify the initial state of context objects. Suggested by Randy to fix
a problem noted by Steve.]
3.6:
Modify the first two paragraphs:
The Element type is a distinct [abstract] type {used to represent} [representing]
handles [for the lexical elements] {on the syntactic constructs}
that form the text of compilation units. Elements deal {both} with
the internal [or] {and the} "textual" view of compilation units.
Operations are provided [that split a Compilation_Unit
object into]{retrieve} one Element and two
Element{_Lists}[ lists]{from an ASIS Compilation_Unit object}:
[Suggested by Tucker, rewritten by Randy, rewritten by Tucker.]
3.7:
Add at the end:
Type Element_List represents a list of elements.
[No text here, noted by Randy. Note that an alternative would be to merge this
clause with 3.6.]
3.9:
Modify the clause:
Element Kinds are enumeration types describing various kinds of
elements. These element kinds are [only] used [by] {within} package
Asis.Elements.
[Suggested by Tucker.]
3.9.1:
Modify the last sentence of the first paragraph:
... Several subordinate kinds [also] have [additional] {further
sub-}subordinate kinds.
[Suggested by Tucker.]
3.9.4:
Modify the first paragraph:
Type Declaration_Kinds classifies declarations and specifications
having defining name{s} [literals].
[Suggested by Tucker.]
Modify the third paragraph:
The following Declaration_Kinds subtypes are not used by ASIS but
are provided for the convenience of the ASIS [implementor] {user}:
[Suggested by Tucker.]
3.9.8:
Add to the end:
Note that an abstract formal subprogram is indicated with the
Has_Abstract query (see 13.10).
[Suggested by Tucker.]
3.9.12:
Modify the second paragraph:
The following Access_Type_Kinds subtypes are not used by ASIS but
are provided for the convenience of the ASIS [implementor] {user}:
[Suggested by Tucker.]
3.9.19:
Modify the first paragraph:
Type Attribute_Kinds describes classifications of [all known] Ada
attributes.
[No mystery attributes included. Suggested by Tucker.]
3.9.22:
Modify the second paragraph:
The comments list a reference to the definition in the Ada Standard
for each clause, and any subordinate kinds. {Note that a private
with clause is indicated by the Has_Private query (see 13.10.3).
Similarly, a limited with clause is indicated by the Has_Limited
query (see 13.10.2).}
[Suggested by Tucker.]
3.10:
Replace the first paragraph:
The type Compilation_Unit is used to represent an Ada compilation unit.
[Suggested by Tucker.]
Modify the penultimate non-code paragraph:
The [abstract] type Compilation_Unit ...
[Suggested by Randy.]
3.12:
Modify clause:
Unit Kinds are enumeration types describing the various kinds of
units. These element kinds are [only] used [by] {within} package
Asis.Compilation_Units.
[Suggested by Tucker.]
3.12.1:
Modify first paragraph:
Unit_Kinds defines the varieties of compilation units [of] {which form}
compilations, including compilations having no compilation units but
consisting of configuration pragmas or comments.
[Suggested by Tucker.]
3.12.2:
Modify first paragraph:
Unit_Classes defines {a} classification of {compilation units according
to whether they are} public[,] {or} private, {declaration or} body, and
{library unit or} subunit.
[Suggested by Tucker.]
3.12.4:
Reordered this to eliminate the interspersed type definition and text. (This
was not marked as a change in the Standard.)
[Suggested by Greg.]
Modify the paragraph:
Dependencies between compilation units may also be introduced by
inline [inclusions] {expansions} (Ada Standard 10.1.4(7)) and for
certain other compiler optimizations. These relations are intended
to reflect all of these considerations.
[Suggested by Tucker.]
Modify the last paragraph:
Child unit C.Z is only part of the Needed_Units if it is needed {according
to the rules of the Ada standard, 10.2(2-7)}.
[Suggested by Tucker.]
3.14:
Add in front of the type definition:
Program_Text provides an abstraction for the program text for a program's source code.
This is the return type for all Image functions.
[No description here, one is needed. Suggested by Greg.]
6.5:
Add ", and returns False otherwise" to the end of the sentence.
[Suggested by Erhard.]
6.7:
Add ", and returns False otherwise" to the end of the sentence.
[Suggested by Erhard.]
6.8:
Delete all but the first two sentences of the third paragraph, and the last two paragraphs
entirely.
[This has nothing to do with Finalize, move the text where it belongs. Suggested by Bill.]
6.9:
Add at the end:
Whenever an error condition is detected, and any ASIS exception is raised,
an Asis.Errors.Error_Kinds value and a Diagnosis string are stored.
The Status function returns the Asis.Errors.Error_Kinds value
for the most recently recorded error.
[Text moved from 6.8. Suggested by Bill.]
6.10:
Add after the first paragraph:
Whenever an error condition is detected, and any ASIS exception is raised,
an Asis.Errors.Error_Kinds value and a Diagnosis string are stored.
The Diagnosis function returns the diagnostic message describing the most
recently recorded error. Note that Diagnosis values are implementation dependent
and may vary greatly among ASIS implementations.
[Text moved from 6.8. Suggested by Bill.]
7.12:
Join the sentences:
...attributes[. Returns]{; otherwise, returns} False {(}if ... False{)}.
7.15, 7.16:
Add ", and returns False otherwise" to the end of the sentence.
[Suggested by Erhard.]
8.3:
Modify the second paragraph:
{Procedure Associate is used}[Used] to give name and parameter associations to
a Context.
[Sentence fragment. Suggested by Randy.]
Modify the third paragraph:
A Context has at most one set of name/parameter values associated with it at any
time. [Name and parameter associations cannot be modified while a Context is open
Previous name and parameters]{If The_Context is not open then any previous Name
and Parameters} associations[ for this Context] are replaced by this call.
[Run-on sentence. Suggested by Steve.]
8.4:
Modify the third paragraph:
Raises ASIS_Inappropriate_Context if The_Context is already open or if it
is {unassociated:}[uninitialized(]
does not have associated name and parameter values[)].
[Define the term "unassociated". Suggested by Randy, to fix the comment noted as 8.6.]
8.6, 8.11, 8.12, 8.13, 8.14:
Replace all uses of "uninitialized" with "unassociated".
[The initial state of a default-initialized context object has to be "uninitialized".
But that clearly requires some initialization, so this is a terrible name and confusing.
We define a new term to replace it. Noted by Steve, wording by Randy. 8.4 and 8.9 are not
included in this list as the wording needs more substantial surgury in those clauses and thus
are discussed separately.]
8.7:
Add ", and returns False otherwise" to the end of the first sentence of the second paragraph.
[Suggested by Erhard.]
8.8:
Replace the second and third paragraphs with:
Returns True if Left and Right denote the same ASIS context
object and that object is open. Returns False otherwise.
["designate" should be "denote" (access types are not necessarily used), "variable" should
be "object" (we need "in" parameters to work!). Wording is confusing. Suggested by Steve.]
8.9:
Modify the first sentence:
The_Context specifies a Context {to query}[with associated name and parameter values].
[This description is expected to explain the use, not restrictions, otherwise we have redundant
text. Suggested by Steve.]
Modify the third paragraph:
Returns False {otherwise (in particular, if}[for any uninitialized] The_Context
{is unassociated)}[variable].
[The second and third paragraphs don't cover all possible results, and they ought to. Suggested
by Steve.]
8.10, 8.11, 8.12, 8.13:
In the first paragraph of each of these clauses, replace "to check" by "to query".
[If we don't have anything else to say about a parameter, the wording we use is "to query".
Suggested by Steve.]
8.10:
Add ", and returns False otherwise" to the end of the first sentence of the second paragraph.
[Suggested by Erhard.]
8.12:
Replce the second and third paragraphs with:
Returns the null string if The_Context is unassociated; otherwise, returns the Name value
associated with The_Context.
[Steve noted that these two conditions overlap. Worded by Randy. It is annoying to put the
unusual condition first, but alternative wordings repeat "Name value" or "associated" or don't
use "unassociated". "Returns the Name value associated with The_Context if one is associated,
otherwise, returns the null string."]
8.13:
Replace the second and third paragraphs with:
Returns the null string if The_Context is unassociated; otherwise, returns the Parameters value
associated with The_Context.
[See 8.12.]
9.1:
Add at the end:
Nil_Container is the value of a Container that represents no container.
[Suggested by Randy, after Erhard.]
9.2:
Add at the end:
Type Container_List represents a list of containers.
[No text here, noted by Steve, worded by Randy. Note that an alternative would be to merge this
clause with 9.1.]
9.8, 9.9:
Add ", and returns False otherwise" to the end of the first sentence of the last paragraph.
[Completeness. Suggested by Erhard.]
10.4:
Modify the paragraph:
[Because Context is limited private, this function is only intended to be used to supply a Context
parameter for other queries. ]This {function can be used to }[conveniently ]eliminate[s] the need to
make the original Context visible at the place of each call where a Context parameter is required.
[The first sentence isn't necessarily true in Ada 2005, and doesn't say anything useful to anyone.
The second sentence gives a usage suggestion that is marginally useful, although it might be
better as a Usage Note. Suggested by Steve.]
10.6:
Modify the second paragraph:
Returns the library_unit_declaration or library_unit_renaming_declaration with the {specified Name}[name],
contained in The_Context.
["name" is ambiguous; make it clear that it is the parameter that we are talking about. Suggested
by Steve.]
10.6-10.10:
Add:
Raises ASIS_Inappropriate_Context with a Status of Value_Error if The_Context is not open.
[This text seems to imply that Nil_Compilation_Unit is returned in this case, rather than raising
an exception. Given our goal of making these descriptions as self-contained
as possible, we ought to say this in these routines. Noted by Steve, suggested by Randy.]
10.11-10.14, 10.32, 10.33:
Raises ASIS_Inappropriate_Context with a Status of Value_Error if The_Context is provided and is not open.
[See previous item. Suggested by Randy.]
10.13:
Replace:
Library_Item expects a unit that has one of the following Appropriate Unit_Kinds:
A_Procedure_Body
A_Function_Body
A_Package_Body
An_Unknown_Unit --
Raises ASIS_Inappropriate_Compilation_Unit with a Status of Value_Error for any unit that does
not have one of these expected kinds.
by:
Library_Item expects a unit of any Unit_Kinds except Not_A_Unit.
Raises ASIS_Inappropriate_Compilation_Unit with a Status of Value_Error if Library_Item
has Unit_Kinds Not_A_Unit.
[See attached e-mail. Essentially, this matches existing practice. The old standard had both, and
we initially picked the wrong one to replace.]
Move the implementation requirements text into the item body, as it is not an Implementation Requirement
in any other clauses.
[Noted by Steve.]
10.14:
Replace:
Library_Item expects a unit that has one of the following Appropriate Unit_Kinds:
A_Procedure
A_Function
A_Package
A_Generic_Procedure
A_Generic_Function
A_Generic_Package
An_Unknown_Unit --
Raises ASIS_Inappropriate_Compilation_Unit with a Status of Value_Error for any unit that does
not have one of these expected kinds.
by:
Library_Item expects a unit of any Unit_Kinds except Not_A_Unit.
Raises ASIS_Inappropriate_Compilation_Unit with a Status of Value_Error if Library_Item
has Unit_Kinds Not_A_Unit.
[See attached e-mail. Essentially, this matches existing practice. The old standard had both, and
we initially picked the wrong one to replace.]
Move the implementation requirements text into the item body, as it is not an Implementation Requirement
in any other clauses.
[Noted by Steve.]
10.15, 10.16:
Add ", and returns False otherwise" to the end of the first sentence of the last paragraph.
[Completeness. Suggested by Erhard.]
10.17, 10.18:
Add ", and returns False otherwise" to the end of the first sentence of the second paragraph.
[Completeness. Suggested by Erhard.]
10.29:
Modify the third paragraph by:
Returns False if the unit is a Nil_Compilation_Unit argument, the {unit does not have the given }Attribute[ does
not exist], or the implementation does not support attributes.
[We don't want to define "exists" here, and if we don't, the two lists are not exclusive. 11.4
has better wording, so we borrowed that. Noted by Steve, but he didn't suggest a solution.]
11.1:
Change:
ASIS uses the predefined Ada.Calendar.Time. ASIS uses the predefined Standard.Duration.
To:
ASIS uses the predefined Ada.Calendar.Time and Standard.Duration for time-related values.
[Suggested by Greg.]
12.1:
Modify the second paragraph under Consistent units list as follows:
Every unit in this list is unique. No duplicates are returned; no two units {A and B} in the
list [are Is_Equal or Is_Identical]{have Is_Equal (A, B) = True}.
[John called this sentence "scruffy". Randy notes that Is_Identical(A,B) = True implies that
Is_Equal(A,B) = True so there is no reason to mention Is_Identical here.]
Modify the second paragraph under Inconsistent units list as follows:
Each pairing defines an inconsistent semantic dependence relationship. The right unit of each
pair semantically depends on the {immediately} preceding left unit. All ...
[Suggested by John.]
13.1:
Remove:
Gateway queries between Compilation_Units and Elements.
[There is only one query here, and what is a "gateway" anyway? Suggested by Randy to reduce John's
confusion.]
13.1, 13.3, 13.5:
Change:
Raises ASIS_Inappropriate_Compilation_Unit with a Status of Value_Error [for any unit that does
not have one of these expected kinds]{if Compilation_Unit has Unit_Kinds Not_A_Unit}.
[John was confused by the original, boilerplate wording because the only kind that is not allowed
is Not_A_Unit. The simpler version should be less confusing.]
13.3:
Modify the third paragraph as follows:
Returns a Nil_Element_List if the {Unit_Kind of the} unit has A_Nonexistent_Declaration, A_Nonexistent_Body,
or An_Unknown_Unit [Unit_Kind].
[Reduce confusion, suggested by John.]
13.22: Operator_Kind
Modify the second paragraph:
Returns the Operator_Kinds value of the [A_Defining_Name or An_Expression] element.
[Reduces confusion and redundancy; the list of expected kinds tells you what kinds of element are allowed,
and repeating it inprecisely isn't helpful. Suggested by John.]
13.29, 13.30: Is_Nil
Add "and returns False otherwise" to the end of the second paragraph.
[Suggested by John and Erhard.]
13.31: Is_Equal
Replace the second paragraph with:
Returns True if Left and Right represent the same physical element
from the same physical compilation unit, and returns
False otherwise. The two elements may or may not be from the same open
ASIS Context variable.
[Suggested by John and Erhard, also removed excess commas.]
13.32: Is_Identical
Replace the second paragraph with:
Returns True if Left and Right represent the same physical element
from the same physical compilation unit from the same open ASIS
Context variable, and returns False otherwise.
[Suggested by John and Erhard, also removed excess commas.]
14.1:
Change State_Information to State in the first paragraph.
[Wrong parameter name. Noted by Gary.]
15.35:
Modify the first paragraph:
Declaration specifies the [rename]{renaming} declaration to query.
[Noted by Gary.]
13.39: Is_Subunit
Replace the second and third paragraphs by:
Returns True if the declaration is the proper_body of a subunit,
and returns False otherwise (including if Declaration has an unexpected
Declaration_Kinds).
[The possibilities are not exhaustive. Noted by Randy.]
15.42:
Change:
Subunit expects an element that has one of the following Appropriate Declaration_Kinds
(Is_Subunit(Declaration) shall also be True)
To:
Subunit expects an element for which Is_Subunit(Declaration) is True and that has one
of the following Appropriate Declaration_Kinds:
[Problem from Greg, wording by Randy.]
15.49:
Remove A_Private_Type_Declaration for the list of expected kinds.
[A private type cannot have a progenitor list. Noted by Gary.]
16.8:
Modify the second paragraph:
Returns the type structure from which the specified type definition has been derived. This
function will recursively unwind derivations and subtyping until the type_declaration
{is a derived type whose parent type has a different representation}[derives a change of
representation] or is {not a derived type}[no longer derived]. See Ada Standard 13.6.
[Confused wording. Noted by Gary, worded by Randy.]
16.37:
Modify the first paragraph:
Type_Definition specifies the task [type]{or protected} definition to query. Include_Pragmas
specifies whether pragmas are to be returned.
[This routine takes both task and protected definitions, it should say that. Suggested
by Gary.]
17.2:
Change the third paragraph:
For string literals, Value{_Image} [will] return{s} the quotes...
[Fix bug, simplify. Suggested by Brad.]
17.3:
Modify the first paragraph:
[Name] {Expression} specifies the name ...
[The name of the parameter is wrong, noted by Brad. The name ought to be "Name" as
documented, but that would be incompatible, and we decided not to make the change
in SI99-0023-1. "Expression specifies the name..." looks idiotic, but it is the truth.]
17.4:
Add:
Within_Element expects any kind of element.
[There is no description of the kind of element expected, there needs to be,
suggested by Brad. Randy used the wording above to show that there is no restriction
on the parameter (which is what the lack of wording probably shows as the intent).
But Brad wonders if this shouldn't be restricted to entities that can have references:
Within_Element expects an element that has the following Element_Kinds:
A_Pragma,
A_Declaration
A_Definition
An_Expression
An_Association
A_Statement
A_Path
A_Clause
An_Exception_Handler
Since that might be incompatible, this was not done at this time.]
17.5:
Modify:
If the Implicitly argument is True:
Returns True if the Name is referenced by either implicit or explicit elements within
the given limits{, and returns False otherwise}.
If the Implicitly argument is False:
Returns True only if the Name is referenced by explicit elements{, and returns False
otherwise}.
[Suggested by Erhard.]
Replace the existing paragraph about expected kinds for Within_Element with:
Within_Element expects any kind of element.
[The current wording was added to provide an answer, but it was supposed to be
a placeholder until it was discussed (which it never was). And the expected
types make no sense. Thus, we use the same wording as in 17.4. Noted by Brad.]
17.6:
Modify the first paragraph of the implementation permission:
Raises ASIS_Inappropriate_Element, with a Status of Value_Error, if passed a
reference that does not have a declaration{, including the following}:
[The wording make it appear that this is not an exhaustive list, and that should
be clear. Noted by Brad, worded by Randy.]
17.13:
Add "mod" to the list of reserved words that can be attribute_designators.
[Added by Ada 2005. Noted by Randy when answering an incorrect comment by Brad.
This was wrong in the Ada Standard, but has been corrected by AI05-0004-1.]
17.18:
Modify the first bullet:
Returns the discrete_choice_list {in} order of appearance {in the program text}. ...
[Suggested by Brad.]
Replace the last two paragraphs by:
Returns a list of elements that each have one of the following Element_Kinds:
An_Expression
A_Definition that has one of the following Definition_Kinds:
A_Discrete_Range
An_Others_Choice
17.19:
Modify the first bullet:
Returns the component_choice_list {in} order of appearance {in the program text}. ...
[Suggested by Brad.]
17.29:
Replace the bullets and the first part of the following paragraph:
Returns a Nil_Element if the:
* *function_*prefix or the operator of an infix call denotes a predefined operator for which the
implementation does not provide an artificial function declaration,
* prefix of the call denotes an implicit or explicit dereference of an access to a function value, or
* argument is a dispatching call.
If the function_prefix or function_name denotes an attribute_reference, and
[Brad asks what is "function_prefix" and how is it different from "prefix of the call"? Randy
thinks that function_prefix (with function in italics) was meant, but this could be wrong as it
doesn't include parameterless calls nor infix calls to operators. Thus the redo.
The first bullet needs to support infix call; the second bullet is a garbled mess (but prefix is OK
there because of the dereference); and the paragraph following the bullets needs to support
parameterless calls (there aren't any currently, but it surely could happen).]
17.30:
Modify:
if the prefix of the call denotes an [access to a function] implicit or explicit dereference
{of an access to a function value},
[The original text is confused. Noted by Brad, worded by Randy.]
18.28: Corresponding_Call_Entity (new clause number)
Replace the bullets and the first part of the following paragraph:
Returns a Nil_Element if the:
* prefix of the call denotes an implicit or explicit dereference of an access to a procedure value, or
* Statement is a call to a dispatching operation of a tagged type which
is not statically determined.
If the procedure_prefix or procedure_name denotes an attribute_reference, and
[The first bullet has been rearranged to make more sense. The first sentence of after the been updated
to handle parameterless procedure calls, see 17.29 for a fully explanation. The second bullet has
been eliminated, as it is the subsumed by the third bullet. Changed "argument" to "Statement" to directly
talk about the parameter. Suggested by Brad and Randy.]
18.29: Call_Statement_Parameters (new clause number)
Modify:
if the prefix of the call denotes an [access to a procedure] implicit or explicit dereference
{of an access to a procedure value},
[The original text is confused. Noted by Brad, worded by Randy.]
20.2:
Add the other subtypes here:
subtype Line_Number_Positive is Line_Number range 1 .. Maximum_Line_Number;
Change the clause title to:
subtypes Line_Number and Line_Number_Positive
[Suggested by Randy.]
20.3:
Delete subclause (moved to 20.3).
[suggested by Randy.]
20.4:
Add a description:
Nil_Line_List is the value of a Line_List containing no elements.
[Suggested by Erhard.]
20.7:
Move note to the end.
[Notes should be last according to the ISO drafting guidelines. Suggested by Randy.]
20.19:
Modify the third paragraph:
Returns a {Nil_Line_List}[Nil_Span] if the ...
[Nil_Span would be the wrong type. Noted by Erhard.]
20.20:
Modify the third paragraph:
Returns a {Nil_Line_List}[Nil_Span] if the ...
[Nil_Span would be the wrong type. Noted by Erhard.]
20.21:
Modify the third paragraph:
Returns a {Nil_Line_List}[Nil_Span] if the ...
[Nil_Span would be the wrong type. Noted by Erhard.]
Modify the fifth paragraph:
Raises ASIS_Inappropriate_Line_Number if {Last_Line is less than
First_Line}[the span is nil]. If the span defines...
[No span in this interface, so we need to say what we mean. Suggested by Erhard.]
20.24:
Modify the third paragraph:
If the Line is the first line from the Lines result for an Element, it {may}[can]
represent only a portion of a line from the original compilation. If the span began
at character position P, the first Line of {its}[it's] Lines result is...
[Wrong word in both cases ("it's" = "it is"); the first was noted by Erhard and
the second by Randy.]
21.1:
Add at end:
Nil_Id is the value of a Id that represents no element.
[Definition was missing. Suggested by Erhard.]
21.5:
Revise the last paragraph:
Returns True if the Id is the Nil_Id{, and returns False otherwise}.
[Suggested by Erhard.]
21.6:
Revise the last paragraph:
Returns True if Left and Right represent the same physical Id[,] from the same physical
compilation unit{, and returns False otherwise}. The two Ids convert to Is_Identical
Elements when converted with the same open ASIS Context.
[Suggested by Erhard.]
22.1:
Delete "Implementation is highly implementation dependent."
[Even if this meant something (which is not obvious), why would the user of ASIS care??
Noted by Erhard, deletion by Randy.]
Add at the end:
Nil_Record_Component is the value of a Record_Component that represents no component.
[No description. Suggested by Erhard.]
22.2:
Add at the end:
Type Record_Component_List represents a list of record components.
[No text here, suggested by Randy. Note that an alternative would be to merge this
clause with 22.1.]
22.3:
Delete "Implementation is highly implementor dependent."
[Even if this meant something (which is not obvious), why would the user of ASIS care??
Noted by Erhard, deletion by Randy.]
Add at the end:
Nil_Array_Component is the value of an Array_Component that represents no component.
[No description. Suggested by Erhard.]
22.4:
Add at the end:
Type Record_Component_List represents a list of record components.
[No text here, suggested by Randy. Note that an alternative would be to merge this
clause with 22.3.]
22.6:
Delete all but the first sentence of the first paragraph.
[Besides talking about indexing an N-dimensional array with a single index value (not
an Ada concept), this is talking about the obsolete data streams. Kill it. Suggested
by Erhard.]
Add at the end:
Nil_Array_Component_Iterator is the value of an Array_Component_Iterator that represents
no iterator.
[No description. Suggested by Erhard.]
22.11:
Modify the second paragraph:
Returns True if Left and Right represent the same physical component of the same record or
array type[,] from the same physical compilation unit{, and returns False otherwise}.
The two components may or may not be from the same open ASIS Context variable.
[Suggested by Erhard.]
22.12:
Modify the second paragraph:
Returns True if Left and Right represent the same physical component of the same record or
array type[,] from the same physical compilation unit and the same open ASIS Context
variable{, and returns False otherwise}.
[Suggested by Erhard.]
22.14:
Add "Returns False otherwise." to the end of the last paragraph.
[Suggested by Erhard.]
22.15:
Add "Returns False otherwise." to the end of the last paragraph.
[Suggested by Erhard.]
22.16:
Modify the last sentence:
Does nothing if the iterator is {Nil_Array_Component_Iterator
or is }already past the last component.
[Unspecified otherwise. Suggested by Erhard.]
22.17:
Add "Has no effect if Iterator is Nil_Array_Component_Iterator." to the last paragraph.
[Unspecified otherwise. Suggested by Erhard.]
22.20:
Modify the third and fourth paragraphs:
The result describes the locations of the record type's discriminants, regardless of the static
or dynamic nature of the record type.[ All return components are intended for use with a data
stream representing a value of the indicated record type.]
All return values are valid parameters for all query operations{ that accept Record_Components}.
[Data streams again and doesn't say anything useful (by Randy); overbroad (by Erhard)]
22.21:
Modify the third and fourth paragraphs:
The result describes the locations of the record type's discriminants and
components.[ All return components are intended for use with a data stream
representing a value of the indicated record type.]
All return values are valid parameters for all query operations{ that accept Record_Components}.
[Data streams again and doesn't say anything useful (by Randy); overbroad (by Erhard)]
22.24:
Add to the end:
Type_Definition expects an element that has the following Element_Kinds:
A_Type_Definition that has one of the following Type_Kinds:
A_Derived_Type_Definition (derived from an array type)
An_Unconstrained_Array_Definition
A_Constrained_Array_Definition
Component expects a component that has Is_Array(Component) = True and that
has one of the following Asis.Data_Decomposition.Type_Model_Kinds:
A_Simple_Static_Model
A_Simple_Dynamic_Model
Raises ASIS_Inappropriate_Element with a Status of Value_Error for any element
or component that does not have one of these expected kinds or types.
[The entire specification of the parameters is missing on these functions. Copied from 22.23.
Suggested by Erhard.]
Annex A
In the entry for Compilation_Unit[type], replace "for which values" with "whose values".
[Suggested by Ed.]
In the entry for Container [type], replace "for which values" with "whose values".
[Suggested by Ed.]
In the entry for Context, replace "Defines a set..." with "A set...".
[Suggested by Ed.]
In the entry for Context [type], replace "for which values" with "whose values".
[Suggested by Ed.]
Replace the entry for Needed Units by
The set of compilation units ultimately needed by the given compilation
unit to make up or to be included in a completed partition.
B.1:
Change title to
An ASIS application to traverse a compilation unit
[Much more descriptive. Suggested by Ed.]
B.2:
Change title to:
An ASIS application to build a call tree.
[Much more descriptive. Suggested by Ed.]
Replace
The ASIS_Call_Tree_Example is demonstrated using a context containing the
following compilation units:
with
Consider the context comprised of the following compilation units:
[Better description. Suggested by Ed.]
Replace
Given a context containing the above set of compilation units, the sample
output resulting from execution of ASIS_Call_Tree_Example is:
with
Applying ASIS_Call_Tree_Example to the context given above yields the
following output:
[Better description. Suggested by Ed.]
Annex C
Change the title of C.3 as noted below. Remove the reference to the current
C.1.
C.1
Remove this entire clause; it depends on an obsolescent package, and is just
a rewrite of Ada.Streams.Stream_IO.
C.3
Change the title to:
Using ASIS with CORBA and IDL
[Better title, suggested by Ed.]
C.3.3
Change the title to:
Implementing generic subprogram Traverse_Element in a CORBA environment
[Better title, suggested by Ed.]
In the first paragraph, replace "should first be created" with
"must first be created"
[This is something required. "Must" is a bad word, but since this is non-normative
crap, we can get away with it. Suggested by Ed.]
C.3.4
Change the title to:
IDL to implement generic subprogram Traverse_Element
[Better title, suggested by Ed.]
Add a new subclause:
D.3.3 Major changes from ASIS for ISO/IEC 15291:1999
The main changes in the ASIS definition are as follows:
• Previous versions of ASIS provided mostly syntactic information regarding an Ada unit
or program. An entire new interface and set of packages was added to provide a semantic
“view” of units. Routines are also provided to allow for easy transition between these
two different views of an Ada program. The semantic view makes it easier to access
information that is otherwise implicit or anonymous.
• New queries and types were added to support language features added or revised by
Amendment 1 (ISO/IEC 8652:1995/AMD 1:2007) such as new kinds of types, new pragmas,
attribute kinds, and use of prefix notation. Existing queries and types were revised
to take into account language changes.
• The expected input types and return types were clarified throughout the standard.
• Restricted some past allowed variability between implementations, increasing the
portability of source transforming tools.
[This is added as the Annex already has a similar listing for the previous ASIS versions.
It would be weird to not have any such listing in the Annex for the current version.
Proposed by Greg, edited by Randy.]
F.5.2 Delete the note.
[Since Traverse_Element (only) calls routines passed in its formal parameters,
this note is possibly False (if one of its formal parameters called this routine),
and otherwise, why would anyone expect this to be called? It's like saying that
Put_Line isn't called by Traverse_Element. So it's junk. Suggested by Greg.]
!discussion
!appendix
From: Randy Brukardt
Sent: Thursday, March 12, 2009 1:24 AM
Greg noted in his review of the ASIS standard:
1.1.4+ I find this whole section as speaking on "how" ASIS is implemented as beyond
what this standard should be talking about. It talks about CORBA only because Alsys
had such an implementation, but even there it supported the ASIS API as the interface.
I agree strongly with Greg. It is none of the standard's business how ASIS is implemented,
so long as the required API is supported.
I don't even see any value for this discussion in an Appendix. Implementors can (and will)
do whatever they want. This is just wasted pages.
Therefore, I think (and I believe Greg agrees) that all 5 of these clauses (1.1.4, 1.1.4.1,
1.1.4.2, 1.1.4.3, and 1.1.4.4) should simply be deleted.
Does anyone object?? If not, I'll do it before we send out the review (so no one has to
waste time reading this).
P.S. I find it annoying that the first two paragraphs of 1.1 Scope repeat the Introduction
that immediately precedes it, but I don't see a good solution to that.
****************************************************************
From: Jean-Pierre Rosen
Sent: Thursday, March 12, 2009 3:55 AM
> Therefore, I think (and I believe Greg agrees) that all 5 of these
> clauses (1.1.4, 1.1.4.1, 1.1.4.2, 1.1.4.3, and 1.1.4.4) should simply be deleted.
No objection. And I think there are certainly other places with useless verbiage
that should be junked.
What? are you asking for a volunteer to review that? Sorry, I think someone is
just calling me... :-)
****************************************************************
From: Tucker Taft
Sent: Thursday, March 12, 2009 5:36 AM
How about moving the material into the Annotated ASIS standard?
Having a possible implementation model can be useful, even if it isn't followed directly.
****************************************************************
From: Randy Brukardt
Sent: Thursday, March 12, 2009 1:46 PM
I suppose we could, but the material really doesn't say anything interesting.
The fact that you *could* implement it as a distributed system (and in various ways)
is pretty obvious, I think. The fact that you could implement a code "browser" on top
of a distributed version of ASIS seems obvious, too. The material reads to me like an
attempt to get various buzzwords into the Standard (IDL, ORB, etc.) But they're the wrong
buzzwords for today. For that we need to describe how ASIS can be implemented with
SOAP and XML in a cloud computing environment hosted on multicore architectures in a
virtual machine. :-)
As Jean-Pierre points out, there is a lot of "sales" material in the ASIS standard
(telling people how great ASIS is and how it will do everything except slice bread),
which never belonged there in the first place and surely does not belong there now.
One minor instance that Greg picked up is that there is a list of possible applications
in the Introduction. That list includes "debuggers", while D.3.1 specifically says that
ASIS was not designed to meet the needs of debuggers. Hype, meet reality. (We deleted
"debuggers" from this list.)
****************************************************************
From: Tucker Taft
Sent: Thursday, March 12, 2009 1:59 PM
Based on how you describe it, I agree with the suggestion to simply delete it.
****************************************************************
From: Greg Gicca
Sent: Thursday, March 12, 2009 2:38 PM
Note that I was tasked in creating test examples for ASIS version 0.7 or
0.8 or some such. I wrote:
dependency order: compile order, re-compile order (given a changed unit),
elaboration order, etc.
complexity metric report generator,
test case generator,
style guide reporting tool,
pretty printer,
stub generator,
and a variety of other programs. These test various levels of ASIS capabilities.
The last 3 were just as unreliable as a debugger application. If the compiler
did things like constant folding (as a simple example) I found that the pretty
printed code, generated bodies, or style were only semantically the same as the
original source and not the same in a legally compilable way. Given the following spec:
procedure Pro (Value : in Integer := The_Constant);
Would screw up all 3 by returning:
procedure Pro (Value : in Integer := 0);
Bad style, changed the source code, different than spec, etc. We can argue whether
the TeleSoft implementation was non con-formant, but you had to jump though hoops to
use the source text features of ASIS to make sure what you got was the same as the
original source.
Funny as we add a semantic interface, when one of the original problems was a
semantic returned value when you wanted a syntactic one. :)
****************************************************************
From: Greg Gicca
Sent: Thursday, March 12, 2009 2:46 PM
> Therefore, I think (and I believe Greg agrees) that all 5 of these
> clauses (1.1.4, 1.1.4.1, 1.1.4.2, 1.1.4.3, and 1.1.4.4) should simply be deleted.
Yes I agree. For review purposes these sections should be renamed as some thing like
"to be deleted" so they are not reviewed, but left in place to maintain the section
numbering for the up coming group review.
****************************************************************
From: Jean-Pierre Rosen
Sent: Friday, March 13, 2009 4:23 AM
I'm puzzled by your example. Do you mean that Telesoft's implementation returned the
view of the tree *after* static evaluation? Is there some wording in ASIS that allows
that to happen? If not, we don't have to care about the effects of something that is
simply not ASIS...
****************************************************************
From: Greg Gicca
Sent: Friday, March 13, 2009 11:50 AM
Right, I said it was non-conformant, e.g it had a bug in its ASIS implementation.
The issue was that the compiler would replace any reference to a constant , in this
example, with the value. So when you later ran ASIS it didn't have the reference
to the constant any more, just the value.
****************************************************************
From: Randy Brukardt
Sent: Wednesday, May 13, 2009 7:33 PM
Because the deadline (Friday) is fast approaching, I need responses ASAP. In all
of these cases, I've already used [A], so if you don't like that, please say something.
Randy.
---
#1:
Clauses 9.2, 22.2, and 22.4 don't have any description. Should I [A] Add "Type
Container_List represents a list of containers." or similar text to each of these clauses;
or [B] Move the declarations into 9.1, 22.1, and 22.3, respectively, and then delete the
clauses that currently hold this text?
I'd rather not do clause deletions in the future as they'll force wholesale renumbering,
which would be best to do only at limited points (right now, as it turns out). I did [A]
for now, but I wonder if [B] isn't better.
----
#2:
Throughout section 8:
Steve noted that this text uses "uninitialized" as a state. (Contexts have three possible
states: "uninitialized", not open, or open.) But "uninitialized" is a horrible name for
a defined state. That's especially true when I added the missing wording to 3.5 that
"A context is default-initialized to the uninitialized state". Yuck.
I tried a number of ways to describe this state before setting on "disassociated". ("not
associated" begs the question of what is not associated, and the full description of "does
not have associated Name and Parameters" is too long to use to replace the 7 existing uses
of the term (along with the new one described above).
But is "disassociated" by itself enough (which is how "uninitialized" was used"), or should
it be "disassociated state" as in the wording above? (And in the existing wording for 8.6.)
For instance, in 8.11:
[A] Returns False if The_Context is disassociated.
[B] Returns False if The_Context has the disassociated state.
I used [A], but I'm not sure.
----
#3:
Clause 8.12 (and 8.13)
The description of what is returned here is not disjoint. It is best to combine these.
[A] Returns the null string if The_Context is disassociated; otherwise, returns the Name
value associated with The_Context.
[B] Returns the Name value associated with The_Context if one is associated, otherwise,
returns the null string.
[A] puts the unusual case first, [B] doesn't use the term disassociated making it look incomplete.
I used [A], but am not sure.
****************************************************************
From: Steve Baird
Sent: Thursday, May 14, 2009 1:00 AM
[A] across the board is fine with me.
Perhaps there exists a better term than "disassociated", but it seems clear to me that this
is a big improvement over "uninitialized" for all the reasons you gave.
****************************************************************
From: Jean-Pierre Rosen
Sent: Thursday, May 14, 2009 2:20 AM
(provided it is acceptable English), I would prefer "unassociated", since "disassociated"
seems to imply that it has been associated in the past.
****************************************************************
From: Randy Brukardt
Sent: Thursday, May 14, 2009 4:33 PM
Well, a number of people complained about "unnormalized", but that term is used throughout
this standard and I don't have the energy (or time/$) to change it. In addition, John
is on vacation so we can't ask our oracle. So, given the precedent, I don't mind
"unassociated", and I changed the text to that. May have to change it again.
****************************************************************
From: Randy Brukardt
Sent: Wednesday, May 13, 2009 9:33 PM
Steve Baird asks:
For 10.13 function Corresponding_Declaration (unit)
According to what is stated here, if Corresponding_Declaration is passed an argument
which is already a library unit spec (e.g., a package declaration) then it simultaneously
"returns a unit that is_Equal to the argument" and "raises ASIS_Inappropriate_Compilation_Unit".
Which is it?
10.14 has the same problem if a body is passed in.
---
The original ASIS standard contained for Corresponding_Declaration:
All Unit_Kinds are appropriate except Not_A_Unit.
Appropriate Unit_Kinds:
A_Procedure_Body
A_Function_Body
A_Package_Body
An_Unknown_Unit -- See Implementation Permissions
which says two different things about when ASIS_Inappropriate_Compilation_Unit is raised.
Greg or I figured the more restrictive version made more sense (no advantage to passing in
junk, and someone had to go through the effort to define these more restrictive lists
-- they could hardly be an accident), and of course we added other wording to make it
clearer when the exception is raised. But, as Steve points out, there is wording to define
what is returned for various Unit_Kinds that aren't even allowed.
Corresponding_Body has the same problem.
This is pretty bad.
My preference is just to delete the text defining the return result for the cases that are
impossible. But that could change the semantics of actual implementations.
My question is, which semantics is actually implemented by ASIS implementations? Do ASIS
programs depend on the more liberal semantics or is it fine to just raise the exception in
all of these cases?
****************************************************************
From: Bill Thomas
Sent: Wednesday, May 13, 2009 11:20 PM
The original standard did not specify that the exception would be raised.
There were two lists of "appropriate" units, one that returned something interesting,
and the other that returned the argument passed in. I agree that the use of "appropriate"
in both lists is pretty unclear, and not helpful.
I suggest we follow that model and not raise the exception.
****************************************************************
From: Randy Brukardt
Sent: Wednesday, May 13, 2009 11:56 PM
...
> I agree that the use of "appropriate"
> in both lists is pretty unclear, and not helpful.
Since the intent of the original standard was that exceptions are raised for
"inappropriate" elements, it's more than "unclear", it is clearly specifying that an
exception be raised. (As clearly as the old standard says about anything...)
> I suggest we follow that model and not raise the exception.
Well, I don't see any "clear" model. If the intent was to specify when an "interesting"
result could be returned, that should have been done with wording that said that -
"Appropriate Unit_Kinds:" in the old standard does not have any qualifications whatsoever.
(Just as importantly, the text already explains what the results are, and repeating that is
bogus.)
In any case, either option requires deleting a large block of text from the original
standard, and that always makes me uncomfortable.
That's why I asked what implementations do and tools depend on, because the best choice
is to do what they actually do/need, not whatever the garbled text said. Because it is
really easy to read this the way I have been, and raise the exception (I'd argue that
it is the only correct way to read the old text, whatever the intent might have been).
****************************************************************
From: Sergey I. Rybin
Sent: Thursday, May 14, 2009 3:17 AM
> My question is, which semantics is actually implemented by ASIS
> implementations? Do ASIS programs depend on the more liberal semantics
> or is it fine to just raise the exception in all of these cases?
For me the old ASIS Standard is 100% clear. It says:
All Unit_Kinds are appropriate except Not_A_Unit.
and this resolves all the questions concerning raising
ASIS_Inappropriate_Compilation_Unit: it should be raised *only* if the argument unit
is Not_A_Unit.
And this is how this query works in existing ASIS implementations.
****************************************************************
From: Randy Brukardt
Sent: Thursday, May 14, 2009 12:48 PM
> And this is how this query works in existing ASIS implementations.
OK, so you just ignore the "Appropriate Unit_Kinds:" list that immediately follows the
above. That's what I needed to know, we obviously deleted the wrong text (that list
should have been deleted instead). I'll get it fixed.
****************************************************************
From: Bill Thomas
Sent: Friday, May 15, 2009 10:18 AM
That list should be titled something like "Appropriate Unit_Kinds returning the
semantically corresponding declaration" rather than just "Appropriate Unit_Kinds",
and the second list could remain as "Appropriate Unit_Kinds returning the argument
Library_Item".
****************************************************************
From: Randy Brukardt
Sent: Friday, May 15, 2009 7:12 PM
Well, it can't use the word "appropriate" because that triggers an exception raise.
And the second list has nothing to do with "appropriate" at all - you surely aren't
going to raise an exception based on the *return* type! In any case, all of that
"appropriate" wording was dumped long ago. Moreover, I don't see any reason that an
A_Function doesn't "semantically correspond" to itself -- all you are doing is adding
confusion.
The reason you're having such trouble coming up with non-confusing wording is that it
simply doesn't make sense to talk about this. We have a very clean definition for this
routine (well, we would if whomever wrote this was concise): "returns the declaration of
the library unit passed in." There is no normative need to say anything more (other than
the very special cases of obsolete or missing units). I suppose there might be a bit of
value to this as a note, but not normatively, because if it is normative, it just adds
redundancy. And redunancy is almost always bad in a standard (because the "equivalent"
definitions often turn out to not be quite the same). Thus I see no reason to keep this
list, and I don't want to waste the time to make this a note.
Indeed, the "These two function calls will always produce identical results" junk that
appears throughout this standard is similar: it adds little (why would you think
otherwise??) and presents a chance for conflicting definitions. Those probably should
all be turned into notes as well. But not this time.
****************************************************************
Questions? Ask the ACAA Technical Agent