CVS difference for ais/ai-00271.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00271.txt

--- ais/ai-00271.txt	2001/07/14 00:01:48	1.2
+++ ais/ai-00271.txt	2001/09/08 01:42:49	1.3
@@ -4550,3 +4550,329 @@
 
 *************************************************************
 
+From: Tucker Taft
+Sent: Monday, July 16, 2001, 5:31 PM
+
+Randy Brukardt wrote:
+> >
+> >    package P is
+> >        type T is separate(C);  -- is completed
+> >                                -- in child "C" of P.
+> >        ...
+> >    end P;
+> >
+> >    package P.C is
+> >        type T is ...
+> >    end P.C;
+>
+> Well, this is almost OK, but I think it has some problems.
+>
+> First, describing the semantics of the name in the separate is going to be
+> interesting. It has to reference something not declared yet, and about all
+> we can say about it is that it is a library unit -- which doesn't even need
+> to exist yet. Indeed, there must be no requirement that it exist.
+
+This is analagous to a subunit.  The subunit need not
+exist at the point when the stub appears, but it logically
+appears there.  So this seems pretty similar.
+
+>
+> Second, restricting the completion to a child is a non-starter. I certainly
+> don't think people would be happy to have to rename all of their packages in
+> order to use this feature. It is particularly bad, because the parent
+> (presumably with the original name) would contain just the partial
+> definitions, while the child would contain the "meat" -- the stuff that
+> exists now. So every reference the package would have to be changed.
+
+Hmmm... I suppose, though this seems like something
+that would have to be mostly for new code.  Also,
+library-unit renaming would allow the child to be
+renamed as a top-level unit.
+
+>
+> Moreover, I don't think such a restriction would work well with Robert
+> Dewar's "only reason for this feature" -- interfacing to Java. If you have
+> two Java classes Class_A and Class_B that are mutually recursive, this idea
+> would force you to introduce not only another package, but one whose name
+> will show up everywhere:
+>
+>     package Java_Stuff is
+>        type Class_A is tagged separate (A);
+>        type Class_A_Access is access all Class_A;
+>        type Class_B is tagged separate (B);
+>        type Class_B_Access is access all Class_B;
+>     end Java_Stuff;
+>
+>     package Java_Stuff.A is
+>        type Class_A is tagged ...
+>        ...
+>     end Java_Stuff.A;
+>
+>     package Java_Stuff.B is
+>        type Class_B is tagged ...
+>        ...
+>     end Java_Stuff.B;
+
+Actually, Java classes are essentially always declared
+in (Java) packages, so the Ada package corresponding
+to the Java package is a natural place for these.
+Also, the pointer type is the one that Java users will
+use.  The package where the operations are declared
+will not be as important if the obj.operation notation
+is used.
+
+>
+> I think it would be much cleaner to say:
+>
+>     package Abstract_A_and_B is
+>        type Class_A is tagged separate (A);
+>        type Class_A_Access is access all Class_A;
+>        type Class_B is tagged separate (B);
+>        type Class_B_Access is access all Class_B;
+>     end Abstract_A_and_B;
+>
+>     with Abstract_A_and_B;
+>     package A is
+>        type Class_A is tagged ...
+>        ...
+>     end A;
+>
+>     with Abstract_A_and_B;
+>     package B is
+>        type Class_B is tagged ...
+>        ...
+>     end B;
+>
+> ...because then the "abstract" package never appears in uses of Class_A or
+> Class_B. Only the declarations of Class_A and Class_B need worry about it.
+
+I guess I am still not convinced.  I think we need some
+real examples, not just package A and B, to see which
+works better.
+
+> It is especially annoying that there is no technical reason (at least that I
+> know) for this restriction: it would just be a language designer's feel for
+> "the best way to do it". There doesn't seem to be any technical need for
+> direct (or any!) visibility on the incomplete type in order to complete it -
+> the type has no operations (primitive or otherwise) anyway. And the
+> visibility of uses doesn't seem to matter either: you just get whatever view
+> you have.
+>
+> So I would make the name a library unit name, and drop any child
+> requirement.
+
+But it seems important to know that a given type is
+completing an incomplete type, because representation
+may depend on this.  I would think we would certainly
+require that that package with the full type "with" the
+package with the incomplete type, so given that, it seemed
+better to just make it into a child, which always implicitly
+"with"s its parent.
+
+>
+> A third point (just a quibble) is that it really is necessary for
+> readability to mention that this type is a completion (even if the name of
+> the type is required to be the same). So, I'd expect to always put in a
+> comment:
+>     -- Completes Abstract_A_and_B.Class_B.
+> It seems like it would be helpful to include this in the syntax somehow,
+> just as is done with subprogram names on "end". (Aside: I sure wish "end
+> record;" was "end <type_name>;", 'cause that's what I write every time
+> anyway. :-)
+>
+> Anyway, it seems that I've volunteered again :-) to write this up. I'm not
+> sure whether to replace AI-271 with this proposal, or to open a third AI for
+> this third approach. Suggestions?
+
+I hate to see a proliferation of AIs which are alternatives
+of the same thing.  I guess I would rather see these all
+part of the same AI, put forth as alternatives.  Once
+we ultimately pick one for further refinement, we will want
+the others in the appendix or rationale as rejected alternatives.
+Hence, it seems to me they all belong in the same AI.
+Perhaps we need to recognize the importance of "alternatives"
+in amendment AIs.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, July 17, 2001, 4:41 PM
+
+Tucker, responding to me responding to him, wrote:
+> > >
+> > >    package P is
+> > >        type T is separate(C);  -- is completed
+> > >                                -- in child "C" of P.
+> > >        ...
+> > >    end P;
+> > >
+> > >    package P.C is
+> > >        type T is ...
+> > >    end P.C;
+> >
+> > Well, this is almost OK, but I think it has some problems.
+> >
+> > First, describing the semantics of the name in the separate is going to be
+> > interesting. It has to reference something not declared yet, and about all
+> > we can say about it is that it is a library unit -- which doesn't even need
+> > to exist yet. Indeed, there must be no requirement that it exist.
+>
+> This is analagous to a subunit.  The subunit need not
+> exist at the point when the stub appears, but it logically
+> appears there.  So this seems pretty similar.
+
+I think you missed the point. In a subunit, there is no attempt to name some
+unit that will exist sometime in the future. The stub is a declaration of a
+some entity, and that entity actually exists there.
+
+OTOH, the unit named in your proposed syntax is not declared anywhere. And the
+appearance in the separate type declaration certainly is not a declaration, nor
+does some random package spec logically exist at this point.
+
+Traditionally, Ada 95 requires the completor to name the completee (think
+"separate" clause in subunits). The partial declaration does not indicate much
+(if anything) about the completor.
+
+Thus, I think it makes the most sense for the completion to indicate that it is
+completing a separate, rather than the separate trying to name the location of
+the completion. (But I don't feel that strongly about this.)
+
+> > Second, restricting the completion to a child is a non-starter. I certainly
+> > don't think people would be happy to have to rename all of their packages in
+> > order to use this feature. It is particularly bad, because the parent
+> > (presumably with the original name) would contain just the partial
+> > definitions, while the child would contain the "meat" -- the stuff that
+> > exists now. So every reference the package would have to be changed.
+>
+> Hmmm... I suppose, though this seems like something
+> that would have to be mostly for new code.  Also,
+> library-unit renaming would allow the child to be
+> renamed as a top-level unit.
+
+Well, I suppose. *I* have existing code that desperately needs this feature,
+and I would certainly want to use it when it is available.
+
+But this means that virtually my entire program would have to be children of
+some parent. The effect would be that every object would have a parent package
+containing the abstract interface; and a child containing the real definition,
+and a library unit renames to a reasonable name.
+
+>...
+>
+> Actually, Java classes are essentially always declared
+> in (Java) packages, so the Ada package corresponding
+> to the Java package is a natural place for these.
+> Also, the pointer type is the one that Java users will
+> use.  The package where the operations are declared
+> will not be as important if the obj.operation notation
+> is used.
+
+I know all of this (with the possible exception of the last), and I don't see
+what it has to do with my point. Every Java object is converted into an Ada
+package. But if incomplete types are restricted to children, each such package
+will necessarily be two such packages. And the real implementation will be in
+a child. So, the package names will not be a direct mapping from Java, and
+you'll need a library renames to get close.
+
+> > It is especially annoying that there is no technical reason (at least that
+> > I know) for this restriction: it would just be a language designer's feel
+> > for "the best way to do it". There doesn't seem to be any technical need
+> > for direct (or any!) visibility on the incomplete type in order to
+> > complete it - the type has no operations (primitive or otherwise) anyway.
+> > And the visibility of uses doesn't seem to matter either: you just get
+> > whatever view you have.
+> >
+> > So I would make the name a library unit name, and drop any child
+> > requirement.
+>
+> But it seems important to know that a given type is
+> completing an incomplete type, because representation
+> may depend on this.  I would think we would certainly
+> require that that package with the full type "with" the
+> package with the incomplete type, so given that, it seemed
+> better to just make it into a child, which always implicitly
+> "with"s its parent.
+
+If your initial statement is true (and it seems to be), then it is imperative
+that the completing declaration include syntax to specify that it is a
+completion. (So all of the reader, the writer, and the compiler knows certainly
+that it is a completion, and of what.) That syntax would necessarily include
+the name of the type being completed, so it follows that the package would
+have to be withed (from the normal visibility rules). Once we have this, there
+doesn't seem to be any need to restrict where this is used.
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, July 17, 2001, 7:11 AM
+
+Robert says:
+
+> The main argument in favor of this feature at all (at least the market
+> argument as opposed to "this would be nice to have") is to mimic C++ and
+> Java existing code. So to me the only strong argument for nested package
+> abstracts would be an argument that they are useful from this point of view.
+> I do not see that this is the case, but am not really familiar enough to say.
+
+I have an entirely different perspective here.  I don't think Rational will
+implement interfacing with C++ or Java in the foreseeable future (I don't think
+we have seen much demand).  On the other hand, mutually dependent types show up
+all the time in OO designs (in particular when mapping a UML model to Ada).  So
+I believe we need a general solution to this issue, regardless of interfacing
+consideration (general doesn't mean overengineered, of course).
+
+I guess different vendors see different user communities...
+
+*************************************************************
+
+From: Erhard Ploederedere
+Sent: Wednesday, July 18, 2001, 6:56 AM
+
+What I would like to see at some point is one write-up that summarizes the
+pros and cons of the three or more approaches in a single document. With
+three or more separate write-ups, these comparisons are harder to make.
+
+I guess I am asking for a summarizing Study Note rather than multiple AIs,
+which describe a single approach each and collect random comments in the
+appendix. This study note may well be the eventual "master AI-171".
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, July 18, 2001, 2:26 PM
+
+Sounds wonderful. Are you volunteering to write it? (So far, with this
+proposal, the person who has floated an idea has been tagged to write it up.)
+
+I know that the limited time I have available will prevent me from doing
+anything like that until at least November. In the mean time, we're going to
+have a meeting, and I need to rewrite several AIs (including the "type
+separate" proposal). We're going to need something to discuss in the mean time.
+
+If you want the simple version, here it is:
+
+    "with type"
+        Con: Can't handle access types (due to representation issues).
+             Implementation needs "psuedo packages" internally.
+             What happens when multiple paths to the same item "meet"?
+        Pro: Easy to describe to users.
+    "package abstract"
+        Con: Heavy, complex mechanism. Complex visibility issues to work out.
+             New kind of compilation unit affects all tools (alternatives
+             avoiding compilation unit has similar effect on tools because the
+             source must be compiled in two different ways).
+        Pro: Handles access types cleanly.
+    "type separate"
+        Con: Must introduce extra packages (either "unnecessary" parents with
+             Tucker's rules or "unrelated" ones with Dan's/Randy's rules).
+             No allocators/deallocators on access types with designated types
+             of this kind.
+             (Probably others, once a proposal is made and picked apart.)
+        Pro: No new kind of units. No new visibility issues. Access types can
+             be handled (representation clauses can be given if needed). Model
+             is easy to understand (it is an extension of existing rules). No
+             run-time implementation problems; the implementation is identical
+             to incomplete-completed-in-body.
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent