CVS difference for ai05s/ai05-0186-1.txt

Differences between 1.6 and version 1.7
Log of other versions for file ai05s/ai05-0186-1.txt

--- ai05s/ai05-0186-1.txt	2010/02/04 07:10:51	1.6
+++ ai05s/ai05-0186-1.txt	2010/02/23 07:31:06	1.7
@@ -3105,3 +3105,374 @@
 at least logically. So this is a very different problem.
 
 ****************************************************************
+
+From: Tucker Taft
+Sent (privately): Thursday, February 4, 2010  11:51 PM
+
+One thing I see emerging in these global annotations which I find intriguing is
+that we are beginning to give mechanisms whereby a global annotation can
+effectively say: my global side-effects include those of <blah>.  This is as
+opposed to going over to <blah>, copying all of its global side-effects into the
+global annotations for this routine that presumably calls <blah>.
+
+From a maintenance point of view, it may be better to simply announce that there
+is an internal call on <blah> inside somewhere, rather than copying the global
+side effects from <blah>. Clearly the global annotations on <blah> might change,
+and if that is true, we might have to go and change the global annotations on
+everything that calls <blah>.  Which would be <blech>!
+
+This seems like a choice that it is nice to be able to provide: for each call
+inside a routine, you can either incorporate the global effects of that call
+into the global effects for the caller, or you can simply include the fact that
+you made such a call in the global annotation.  I would think the name of the
+subprogram would be an appropriate way to indicate that in the global "object"
+list.
+
+For type-related annotations, you would have the same choice.  And as suggested
+in my earlier response, I might suggest:
+
+   global in out => (new <type_name>)
+
+as a way to indicate that global effects of creating/adjusting/finalizing an
+object of the given type should be assumed for the routine with the given global
+annotation.
+
+It becomes interesting when you call a formal subprogram, or you create an
+object of a formal type.  In those cases you clearly can't incorporate the
+global effects of these operations directly, but instead you can only admit the
+fact that you are doing these things.  Similarly, for a call through an
+access-to-subprogram value, you can't easily incorporate the global effects, but
+you can admit that you are making such a call. Here I would expect something
+like:
+
+   global in out => (acc_to_subp_param.all)
+
+as a way of indicating that a call is made through the given acc_to_subp_param,
+and whatever side effects that implies should be assumed. If you don't or can't
+indicate the particular acc-to-subp value through which you are calling, could
+use the type name instead:
+
+   global in out => (acc_to_subp_type.all)
+
+Presuming I understand the intent, it seems important to distinguish the forms
+of Annotation_Item which are specifying some "direct" global side-effect, versus
+when we are essentially specifying a global side-effect *indirectly* in terms of
+some other subprogram being called or some specified type being
+created/adjusted/finalized.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent (privately): Thursday, February 4, 2010  12:13 AM
+
+> One thing I see emerging in these global annotations which I find
+> intriguing is that we are beginning to give mechanisms whereby a
+> global annotation can effectively
+> say: my global side-effects include those of <blah>.  This is as
+> opposed to going over to <blah>, copying all of its global
+> side-effects into the global annotations for this routine that
+> presumably calls <blah>.
+
+Right. I found that without some way to do that for generics, all was lost.
+
+On the other hand, I decided it was necessary to move away from it for access
+types, because it doesn't model what really happens in the body.
+
+>  From a maintenance point of view, it may be better to simply announce
+> that there is an internal call on <blah> inside somewhere, rather than
+> copying the global side effects from <blah>.
+> Clearly the global annotations on <blah> might change, and if that is
+> true, we might have to go and change the global annotations on
+> everything that calls <blah>.  Which would be <blech>!
+
+That might make sense for visible routines, although it seems to be exposing a
+lot about the body: that could be bad of maintainance removes the call to
+<blah>. Maybe the least of two evils.
+
+> This seems like a choice that it is nice to be able to
+> provide: for each call inside a routine, you can either incorporate
+> the global effects of that call into the global effects for the
+> caller, or you can simply include the fact that you made such a call
+> in the global annotation.  I would think the name of the subprogram
+> would be an appropriate way to indicate that in the global "object"
+> list.
+
+Resolution of the list is going to be a nightmare. There is also the problem of
+overloading (which I was planning to talk about tomorrow if we got past the
+"big" issues): just giving the name of a subprogram isn't enough -- different
+overloaded versions have different annotations. Just look at the vectors example
+in the AI:
+
+   function Element (Container : Vector;
+                     Index     : Index_Type)
+      return Element_Type with
+      Global in out => (generic Element_Type);
+      -- Creates an element.
+
+   function Element (Position : Cursor) return Element_Type with
+      Global in  => (access Vector, generic Element_Type),
+      Global out => (generic Element_Type);
+
+If you say "Ada.Containers.Bounded_Vector.Element" in an annotation, which of
+these annotations do you get? And I can easily imagine that the annotations
+could be more different than these.
+
+> For type-related annotations, you would have the same choice.
+>  And as suggested in my earlier response, I might suggest:
+>
+>    global in out => (new <type_name>)
+>
+> as a way to indicate that global effects of
+> creating/adjusting/finalizing an object of the given type should be
+> assumed for the routine with the given global annotation.
+
+That looks too much like an allocator to me.
+
+> It becomes interesting when you call a formal subprogram, or you
+> create an object of a formal type.  In those cases you clearly can't
+> incorporate the global effects of these operations directly, but
+> instead you can only admit the fact that you are doing these things.
+> Similarly, for a call through an access-to-subprogram value, you can't
+> easily incorporate the global effects, but you can admit that you are
+> making such a call.
+> Here I would expect something like:
+>
+>    global in out => (acc_to_subp_param.all)
+>
+> as a way of indicating that a call is made through the given
+> acc_to_subp_param, and whatever side effects that implies should be
+> assumed.
+
+This makes no sense at all. You have to declare those side effects somewhere,
+there is no possible way to assume them. And once you have them, the rules
+follow from the call.
+
+I really don't like the ".all" syntax, because it is ambiguous with
+<object_name>, so there can be no syntax marker as to what is expected. Meaning
+resolution is a nightmare (resolving for subprogram names, subtype names, and
+object names all at the same time is something you never do in any other context
+-- you could almost do it if you feed back the legality rules to control the
+resolution, but Ada doesn't allow that. Example: if T is a subtype name, T(A) is
+an object, T.all is an object; but you want to interpret it as a subtype name
+and magic syntax. How do you do that??
+
+> If you don't or can't indicate the particular acc-to-subp value
+> through which you are calling, could use the type name instead:
+>
+>    global in out => (acc_to_subp_type.all)
+>
+> Presuming I understand the intent, it seems important to distinguish
+> the forms of Annotation_Item which are specifying some "direct" global
+> side-effect, versus when we are essentially specifying a global
+> side-effect *indirectly* in terms of some other subprogram being
+> called or some specified type being created/adjusted/finalized.
+
+This I agree with, but you aren't doing that (at least with viable syntax).
+
+****************************************************************
+
+From: Steve Baird
+Sent (privately): Thursday, February 4, 2010  2:53 PM
+
+>>> Do we deal with ... finalization of aggregate temps?
+
+> I don't know, because I don't know what you mean by an "aggregate temp".
+
+I was wondering about the annotations for a subprogram Foo that contains, for
+example, the following construct:
+
+    if Some_Controlled_Type'(<aggregate>) in Some_Subtype then
+     ...
+    end if;
+
+The Finalize routine for Some_Controlled_Type will be invoked.
+What rule in the AI requires that this be reflected in the annotations of Foo?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent (privately): Thursday, February 4, 2010  3:05 PM
+
+Ah. Luckily, this is Bob's problem now. ;-)
+
+A more realistic example would be:
+
+      Count := Fancy_Operation (Some_Controlled_Type'(<aggregate));
+
+And note of course that you can't necessarily know that the object is
+controlled. So we would need a rule like:
+
+* The type of every aggregate given in the subprogram shall have a compatible
+  Global in annotation.
+
+Note that "given in the subprogram" here means syntactically, as do all of these
+other rules; things that happen in other callable entities are necessarily
+included in their annotations, and their annotations already have to be
+compatible. (Not sure if there is better wording for that, I'm sure Bob will
+figure it out.)
+
+****************************************************************
+
+From: Steve Baird
+Sent (privately): Thursday, February 4, 2010  5:06 PM
+
+The word "syntactically" is a bit of hyperbole, but I know what you mean.
+
+In particular, I'm thinking about defaulted parameters, e.g.
+     Some_Controlled_Type'(<aggregate>) in Some_Subtype as a default parameter
+     value.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent (privately): Thursday, February 4, 2010  5:11 PM
+
+Right, default expressions are considered to directly appear at the point of the
+call. That has to be true for simple object reads and writes, not to mention
+more complex stuff like allocators and aggregates. So you are right that the
+rules aren't quite purely syntactic. I just don't like "given in" much, as it is
+so vague. Not sure what the best phrasing is.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 4, 2010  4:35 PM
+
+Bob Duff asked that I send out a paragraph or two summarizing my "high-level"
+view of this AI.  So here goes...
+
+A Global in/out annotation specifies the global side-effects of a subprogram
+call, the creation (adjustment/finalization) of an object, the elaboration of a
+package, etc.  Each item in the list of items given in a Global annotation can
+be viewed as specifying a set of objects, and it is the union of those sets that
+are the objects that can be read (for an "in") or written (for an "out") by the
+given operation.
+
+Initially we had considered the Global annotation items to simply be object
+names.  But as the AI has evolved, we have come up with additional syntax to be
+able to specify other sets of objects:
+
+   <object_name> -- the named object, and all of its
+                    subcomponents
+   null          -- the empty set
+   others        -- the universal set
+   others in <pkg> -- all objects declared in <pkg>,
+                    and all objects designated by
+                    pool-specific access types declared in <pkg>
+   access <type> -- all objects of the given type
+                    that might be designated by an
+                    access value
+   <access_type> -- all objects that might be
+                    designated by an access value
+                    of the given pool-specific access type
+   generic <formal_type> -- all objects specified in the
+                    corresponding Global annotation
+                    on the actual type corresponding
+                    to the given formal type, representing
+                    the global side-effects of the creation,
+                    adjustment, or finalization of objects
+                    of the given type.
+
+For what its worth, Tuck has suggested the following specifications as possible
+additions and/or replacements:
+
+   new <type>    -- all (global) objects that might be side-affected
+                    by the creation, adjustment, or finalization
+                    of objects of the given type.  [This replaces and
+                    generalizes "generic" so that it works
+                    with any <type>, not just a generic formal
+                    one.]
+
+   <subprogram_name> -- all objects that might be affected
+                    by calling the given subprogram.  This
+                    may be of the form "acc-to-subp-param.all".
+                    The subp name must not be overloaded [or
+                    we union across all overloadings?].
+
+   aliased <type> -- all objects of the given type that might
+                    be designated by an access value.
+                    [This would replace "access <type>".]
+
+   <acc_type>.all -- all objects that might be designated
+                    by an access value of the given pool-specific
+                    access type.  [This would replace "<acc_type>".]
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 4, 2010  9:00 PM
+
+...
+> Initially we had considered the Global annotation items to simply be
+> object names.  But as the AI has evolved, we have come up with
+> additional syntax to be able to specify other sets of objects:
+
+Note that the AI evolved through writing examples.
+
+>    generic <formal_type> -- all objects specified in the
+>                     corresponding Global annotation
+>                     on the actual type corresponding
+>                     to the given formal type, representing
+>                     the global side-effects of the creation,
+>                     adjustment, or finalization of objects
+>                     of the given type.
+
+This also allows <formal_subprograms> and <formal_in_out_objects>. The need to
+cover formal subprograms should be obvious (assume-the-worst on "=" passed in is
+not good!). Formal in out objects are like renames, and thus they can reference
+global objects. Interestingly, formal in objects (which are always copies) are
+effectively local to the generic (from the perspective of inside the generic) as
+they always are declared at the point of the instantiation. So they don't need
+to be covered in an annotation.
+
+> For what its worth, Tuck has suggested the following specifications as
+> possible additions and/or replacements:
+>
+>    new <type>    -- all (global) objects that might be side-affected
+>                     by the creation, adjustment, or finalization
+>                     of objects of the given type.  [This replaces and
+>                     generalizes "generic" so that it works
+>                     with any <type>, not just a generic formal
+>                     one.]
+
+This only covers the <formal_type> use; you'll also need to cover the other two
+uses.
+
+>    <subprogram_name> -- all objects that might be affected
+>                     by calling the given subprogram.  This
+>                     may be of the form "acc-to-subp-param.all".
+>                     The subp name must not be overloaded [or
+>                     we union across all overloadings?].
+
+I suppose you could cover formal subprograms here. Not overloaded will never
+fly, the first thing I tried to write in a generic was "=". I concluded that no
+solution I could think of would work - the union idea will often lead to using
+(others): predefined "=" is usually (others) for private types. (I used full dot
+notation in the example, but even that is ambiguous with the "=" for type
+Vector.) I'm glad I've passed the torch on this AI to Bob...
+
+>    aliased <type> -- all objects of the given type that might
+>                     be designated by an access value.
+>                     [This would replace "access <type>".]
+>
+>    <acc_type>.all -- all objects that might be designated
+>                     by an access value of the given pool-specific
+>                     access type.  [This would replace "<acc_type>".]
+
+I don't like this syntax as it is ambiguous with object_name. That will
+complicate resolution given that there is no key whether you are resolving for
+"object of any type" or "subtype" (and these are very different). Since I've
+raised this before and essentially been told that I don't know what I'm talking
+about, I won't say any more. (But I'll swear like a sailor when I have to
+implement it...)
+
+Humm, actually, I do have to say more. Adding <subprogram_name> alone is even
+worse: you'll have overlap between <object_name> and <subprogram_name> since a
+parameterless <function_call> and a <function_name> are indistinguishable. I
+suppose you could have some goofy preference rule to deal with that overlap
+(<function_call> never being legal in this context), but that seems way over the
+top to me.
+
+Now I'll go away...
+
+****************************************************************

Questions? Ask the ACAA Technical Agent