Version 1.2 of si99s/si99-0047-1.txt
!standard 1.1 09-03-11 SI99-0037-1/01
!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 Correstions
!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:
Drop "debuggers, " from the Second paragraph.
[D.3.1 says that ASIS specifically was not designed to support debuggers. So why is
it in this list?? - suggested by Greg]
1.1:
Drop "debuggers, " from the Second paragraph.
[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)]
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 penultimate sentence 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.
[Moved the statement deleted from the previous clause here, and generalized
it 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.]
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 allows 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.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.]
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.]
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.]
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.]
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.7:
Move note to the end.
[Notes should be last in the ISO drafting guidelines. Suggested by Randy.]
!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.
****************************************************************
Questions? Ask the ACAA Technical Agent