CVS difference for ais/ai-50217.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-50217.txt

--- ais/ai-50217.txt	2003/09/23 03:47:49	1.8
+++ ais/ai-50217.txt	2003/09/30 02:01:17	1.9
@@ -3547,7 +3547,7 @@
 -----------------
 Thoughts on the implementation of "limited with" in AdaMagic
 
-          $Revision: 1.8 $ $Date: 2003/09/23 03:47:49 $
+          $Revision: 1.9 $ $Date: 2003/09/30 02:01:17 $
 
 The "limited with" clause makes a "limited view"
 of a package visible in the compilation unit
@@ -5356,7 +5356,7 @@
 -----------------
 Thoughts on the implementation of "limited with" in AdaMagic
 
-          $Revision: 1.8 $ $Date: 2003/09/23 03:47:49 $
+          $Revision: 1.9 $ $Date: 2003/09/30 02:01:17 $
 
 The "limited with" clause makes a "limited view"
 of a package visible in the compilation unit
@@ -9275,6 +9275,180 @@
 in a (run-time) elaboration order that results in additional ABE checks
 being necessary. I think I have convinced myself that these are already
 language defined checks, but that get optimized away currently.
+
+***************************************************************
+
+From: Ed Schonberg
+Sent: Sunday, September 28, 2003  4:04 PM
+
+!standard 10.01.02   (03)                           03-04-03  AI95-00217-06/02
+!standard 10.01.02   (04)
+!standard 10.01.02   (08)
+!standard J.10       (00)
+!class amendment 03-02-04
+!status work item 03-02-04
+!status received 03-02-04
+!priority Medium
+!difficulty Hard
+!subject Limited With Clauses
+
+This is a summary of our implementation of Limited_With clauses in GNAT.
+In a nutshell: after a few false starts, the implementation proved to be
+straightforward, thanks to a critical suggestion from Tucker. The changes
+to various phases of the compiler were very localized, and amounted to no
+more than a few hundred lines of code. We reused some of the machinery of our
+implementation of now-discarded With_Type clauses. The current prototype
+implementation is complete, except for one exception mentioned below.
+
+Overview
+--------
+
+GNAT is a source-based compiler. If unit U1 has a limited_with clause that
+mentions unit U2, then U2 must be present in the environment. U2 is parsed,
+and its abstract syntax tree is constructed. The tree is not analyzed, but
+undergoes a simple processing that identifies type declarations in the
+visible part of the unit (and the visible part of nested packages). These
+type declarations are used to created shadow entities in the tree, that
+receive the semantic annotations that describe incomplete types. These
+shadow entities are made visible while the limited_with_clause is effective.
+In a context where a regular with_clause on U2 is effective, the shadow
+entities are invisible. Most of the implementation code handles the
+installation and removal of the shadow entities and their counterparts,
+within the data structures that implement the visibility rules.
+
+There are small changes to the basic type-checking routine, to some binder
+routines, and to the parser. These changes amount to less than 50 lines of code.
+
+Semantics.
+----------
+
+The semantic complications introduced by this construct arise from cases
+of multiple access paths: in a given context, an entity may be available
+through a limited_with_clause, as well as through a regular_with clause,
+a renaming, direct visibility in a child, etc. The proposed legality rules
+for limited_with_clauses make some of these cases illegal, and otherwise try
+to minimize the disruption that the addition of such a clause might have
+on an existing program.
+
+At first sight, the limited_view of a type is analogous to the partial
+view of a private type, and a similar implementation model suggests itself.
+In GNAT, for entities with multiple views, it is always the case that there
+is a single tree node (a defining_occurrence) that holds the current view of
+the entity. In the case of a private type, the occurrence in the
+private declaration (that is to say, the specific node in the abstract
+syntax tree that is the defining_identifier of the declaration) is used to
+denote the entity. Its contents are swapped with the semantic information of
+the full view when needed (i.e. when compiling the private part, the package
+body, or the private part or body of a child unit), but at all times it is the
+same node in the syntax tree that embodies the identity of the type. Our first
+implementation attempt therefore treated the limited_view in the same way:
+the semantic information attached to the entity was either incomplete or
+complete, but the same node of the AST was used in all cases.
+
+However, this model cannot handle correctly cases of multiple access paths,
+because it assumes that at a given point, only one of the possible views is
+available. However, there are cases when two components of a construct
+denote different views of the same type.
+
+The most common usage of limited_with_clauses involves multiple
+access paths: if a specification for package P has a limited_with_clause in
+order to import some type T from package Q, it is usually the case that the
+body of P will have subprogram bodies that manipulate T, and thus the body of
+P will have a regular with_clause on Q. Thus, in the body of P, the type T is
+available both through the limited_with_clause on the library_unit, and the
+regular with_clause on the body. In such a case the desired semantics are
+obvious: the non-limited view of T is available.
+In other cases, the semantics are more subtle, as in the following example:
+
+Consider a package A that declares a type TA, a package P that has a limited
+view of A, and a package Q that has a non-limited view of A. Both P and Q
+declare acces types whose designated type is TA. In context where both P
+and Q are visible (but A might not be), objects designated with these access
+types must be compatible, even though one of them denotes the limited view of
+TA and the other the non-limited view.
+
+As a consequence, we must treat the limited_view of a type as an entity in
+its own right, and add special type resolution rules to make the limited
+and non-limited views compatible. We introduce shadow entities to hold the
+limited_views, and links between the shadow entity and its partner, to
+simplify type-checking. It turns out that these shadow entities (which
+collectively correspond to the "abstract" of the package)  make the
+implementation simpler that the one-entity model with a swapping mechanism
+between views. They also make it easier to maintain necessary invariants
+between the semantic analyzer and the back-end (that is to say the tree
+transducer that uses the Ada AST to build the GCC tree).
+
+Implementation details.
+-----------------------
+
+The changes to compiler internals are only of interest to GNAT maintainers.
+It may be worth listing the following:
+
+a) There were small changes in the contents of AST nodes for with_clauses,
+for package declarations, and for type declarations.
+
+b) The package that handles compilation units and the processing of
+context clauses was obviously the most affected. The following subprograms
+were added:
+
+Build_Limited_View: to create an incomplete (shadow) entity.
+
+Install_Limited_Withed_Unit: to make the incomplete entities visible
+
+Remove_Limited_With_Clause: to remove the incomplete entities from visibility
+
+Expand_Limited_With_Clause: to generate limited_with clauses on the ancestors
+of a unit that is mentioned explicitly in a limited_with clause (as long as
+those ancestors are not mentioned in an effective regular with_clause).
+
+In addition, the following existing routines had to be modified to make use of
+the above (names should be self-explanatory): Analyze_Compilation_Unit,
+Analyze_With_Clause, Install_Context_Clauses, and Remove_Context_Clauses.
+
+c) The package that handles type declarations was modified to retrieve the
+non-limited view (when available) of the designated type of an access type
+that denotes the limited view.
+
+d) There were a few modifications to the binder, to prevent limited_with
+clauses from creating semantic dependencies (that's the whole point, after
+all!).
+
+e) Finally, there were small modifications to error checking and reporting:
+half-a-dozen error messages were added, and some error conditions disabled
+when dealing with limited views.
+
+To test the implementation on the examples proposed in various versions of
+this AI, we also modified the processing of subprogram declarations, to allow
+tagged incomplete formal parameters. All the examples compiled properly
+(or were rejected correctly).
+
+Pending.
+--------
+The single gap in the implementation is the rule that requires the closure of
+a partition to include the body of a unit that is mentioned in a limited_with
+clause, when there is no regular with_clause on that unit elsewhere in the
+partition. This is a bind-time rule that is simple enough to implement: we
+did not have time to include yet, and suspect that partitions that require it
+will be execeedingly rare.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Sunday, September 28, 2003  4:26 PM
+
+Cool!  Glad I made a useful suggestion.
+Which one was it?
+
+***************************************************************
+
+From: Ed Schonberg
+Sent: Sunday, September 28, 2003  8:17 PM
+
+That the limited views be full-blown new entities, rather than
+transient attributes of existing ones. As usual, there is no
+design problem that can't be solved with an additional level of
+indirection. In any case, thanks again for sending us on the right
+path!
 
 ***************************************************************
 

Questions? Ask the ACAA Technical Agent