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

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

--- ai05s/ai05-0138-1.txt	2009/11/25 00:50:44	1.7
+++ ai05s/ai05-0138-1.txt	2010/01/17 03:34:36	1.8
@@ -7355,9 +7355,19 @@
 Sent: Wednesday, March 11, 2009  8:00 PM
 
 I don't think that has ever happened to me, for two^H^H^Hthree reasons:
-(A) I'd rather pass the object itself than an access to it. So if a subsystem needs an access to an object, it has to make the access itself from the parameter (there is a convinient rule that makes all tagged parameters aliased). That falls under case (3
), because the lifetime of the parameter cannot be assumed to be anything in particular.
-(B) In all of the programs that I've written with multiple phases, either each phase is a separate program (Janus/Ada, Jasm), the phases work on a global data structure and don't take any parameters (Jlink, COrder), or the objects that are processed are a
llocated from a (global) storage pool (Trash-Finder, AdaServer). Most of these are older designs; I'm not sure exactly what I'd do today.
-(C) Phases often include multiple calls; there's not necessarily one long-lived processing routine (that's have the Claw Builder is structured).
+(A) I'd rather pass the object itself than an access to it. So if a subsystem
+    needs an access to an object, it has to make the access itself from the
+    parameter (there is a convinient rule that makes all tagged parameters
+    aliased). That falls under case (3), because the lifetime of the parameter
+    cannot be assumed to be anything in particular.
+(B) In all of the programs that I've written with multiple phases, either each
+    phase is a separate program (Janus/Ada, Jasm), the phases work on a global
+    data structure and don't take any parameters (Jlink, COrder), or the objects
+    that are processed are allocated from a (global) storage pool (Trash-Finder,
+    AdaServer). Most of these are older designs; I'm not sure exactly what I'd
+    do today.
+(C) Phases often include multiple calls; there's not necessarily one long-lived
+    processing routine (that's have the Claw Builder is structured).
 The subsystem that processes a phase is at library level.
 
 Even so, this case seems to be exactly the description of case (2): the object
@@ -8076,11 +8086,14 @@
 to learn. Ours uses Instances and Handles;
 
 package Instances is
-type Instance_Base is abstract tagged limited private; type Handle is access all Instance_Base'Class; for Handle'Storage_Size use 0;
+   type Instance_Base is abstract tagged limited private;
+   type Handle is access all Instance_Base'Class;
+   for Handle'Storage_Size use 0;
 
 with Instances;
 package Gen_Class is
-type Instance (<>) is new Instances.Instance_Base with private; type Handle is access all Instance;
+type Instance (<>) is new Instances.Instance_Base with private;
+type Handle is access all Instance;
 
 Conversions to/from Instances.Handle aren't that common, when they do occur it's
 an idiom that people (have to) get used to. Some of the need for user-written
@@ -8385,12 +8398,21 @@
 > irrespective of the context and that these allocations can be safely
 > deallocated.
 
-This latter would be the worst kind of incompatibility (technically, an "inconsistency"). Programs written on compilers that provide the behavior suggested by the current Implementation Advice would still compile and most likely would pass their tests, bu
t they would be leaking memory. Which probably would run out at the worst possible time in a deployed system (for instance, during landing of an aircraft).
+This latter would be the worst kind of incompatibility (technically, an
+"inconsistency"). Programs written on compilers that provide the behavior suggested
+by the current Implementation Advice would still compile and most likely would pass
+their tests, but they would be leaking memory. Which probably would run out at the
+worst possible time in a deployed system (for instance, during landing of an aircraft).
+
+Remember, this is an Ada 95 feature and lots of deployed programs probably depend on
+it in some way. Janus/Ada does issue a warning about leaking on such allocators,
+but we can get away with that because we never implemented the IA. Compilers that
+did implement that IA couldn't do so.
+
+We could make such allocators illegal (that would tell users at compile-time to change
+their code), but I don't think that I can convince the others to make such a change.
+The best I'm hoping for is a restriction pragma, which admittedly is almost no help at all.
 
-Remember, this is an Ada 95 feature and lots of deployed programs probably depend on it in some way. Janus/Ada does issue a warning about leaking on such allocators, but we can get away with that because we never implemented the IA. Compilers that did imp
lement that IA couldn't do so.
-
-We could make such allocators illegal (that would tell users at compile-time to change their code), but I don't think that I can convince the others to make such a change. The best I'm hoping for is a restriction pragma, which admittedly is almost no help
 at all.
-
 We probably can make limited fixes to anonymous access types to fix the limited
 with problem and perhaps some others without too much incompatibility, but I'm
 pretty sure we can't give you your nirvana.
@@ -8525,7 +8547,8 @@
 > "object" in it's Ada sense; O-O dogma gives this concept a different
 > name which I forget at the moment. Ada logically operates directly on
 > objects and does not show the "under-the-hood" references very often.
-> It's this nature that allows Ada O-O objects to be stack allocated, directly placed in containers, etc.
+> It's this nature that allows Ada O-O objects to be stack allocated, directly
+> placed in containers, etc.
 >
 > Thus, dispatching on access values is fundamentally not Ada. I know
 > that a number of us opposing having any solution to this problem in
@@ -8575,8 +8598,8 @@
 > potential for dangling accesses). I agree; I've been searching for a
 > way to make this safe automatically for years, but such ways are
 > pretty expensive. (Both the runtime accessibility check and the
-> parameter passing of tagged objects would require runtime overhead whether or not the feature is used.
->
+> parameter passing of tagged objects would require runtime overhead whether or
+> not the feature is used.
 
 Another way is via preconditions on P that would tell clients that you can't
 pass it local objects
@@ -9406,5 +9429,257 @@
 the place which really doesn't improve readability or safety.
 
 Anyway - just my 2 cents.
+
+****************************************************************
+========= New thread about limited with problems with the 'Ref proposal ========
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, March  9, 2009  2:31 PM
+
+Section 5.9 of the 'Ref proposal states that the limited view of a package
+includes a full view of each 'Ref[_Const] type declared in that package.
+
+I see some problems with this.
+
+An access type is not completely characterized by its designated subtype and its
+point of declaration; there are also representation attributes.
+
+Consider the following modification of the example given in section 5.9 of the
+proposal:
+
+    limited with B;
+    with ... ;
+    package A is
+       type A_Type is tagged record
+          CB : B.B_Type'Ref;
+       end record;
+
+       Storage_Pool_For_A : ... ;
+       for A_Type'Ref'Storage_Pool use Storage_Pool_For_A;
+
+       type Float_Ref is access Float;
+       for Float_Ref'Storage_Pool use B.B_Type'Ref'Storage_Pool;
+       Float_Ptr : Float_Ref := new Float'(0.0);
+    end A;
+
+    limited with A;
+    with ... ;
+    package B is
+       type B_Type is tagged record
+          CA : A.A_Type'Ref;
+       end record;
+
+       Storage_Pool_For_B : ... ;
+       for B_Type'Ref'Storage_Pool use Storage_Pool_For_B;
+
+       type Float_Ref is access Float;
+       for Float_Ref'Storage_Pool use A.A_Type'Ref'Storage_Pool;
+       Float_Ptr : Float_Ref := new Float'(0.0);
+    end B;
+
+The situation with Size and Alignment specifications is at least as bad. And
+Some_Other_Package.Some_Type'Ref may be passed as an actual parameter in an
+instantiation of a generic which depends on these attributes in its body. And
+streaming attributes.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March  9, 2009  3:38 PM
+
+> I see some problems with this.
+>
+> An access type is not completely characterized by its designated
+> subtype and its point of declaration; there are also representation
+> attributes.
+
+Right. That's why we eventually gave up on including named access types in the
+limited view. We surely tried to make that work, but we just could not do so
+without putting all kinds of restrictions on the implementation. That's why we
+turned to anonymous access types in the first place.
+
+Thus, unless we want to essentially disallow aspect clauses for 'Ref, it can't
+be exported in a limited view. In that sense, I don't see any difference between
+'Ref and a named access type.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, March  9, 2009  4:53 PM
+
+> Thus, unless we want to essentially disallow aspect clauses for 'Ref,
+> it can't be exported in a limited view. In that sense, I don't see any
+> difference between 'Ref and a named access type.
+
+I agree, but you have implicitly raised an angels-on-the-head-of-a-pin sort of
+question:
+
+    If a limited view of a package exports an incomplete view of some
+    type T, does it also export an *incomplete* view of T'Ref?
+
+I think the answer should be no, and that is a difference between a 'Ref type
+and a "normal" named access type.
+
+I freely acknowledge that I am prematurely descending into corner-case details
+(yet again).
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, March  9, 2009  6:16 PM
+
+> I agree, but you have implicitly raised an angels-on-the-head-of-a-pin
+> sort of question:
+>
+>     If a limited view of a package exports an incomplete view of some
+>     type T, does it also export an *incomplete* view of T'Ref?
+>
+> I think the answer should be no, and that is a difference between a
+> 'Ref type and a "normal" named access type.
+>
+> I freely acknowledge that I am prematurely descending into corner-case
+> details (yet again).
+
+If full views aren't available for 'Ref types, then the sort of example shown in
+the 'Ref proposal won't be possible.  (And I don't think that incomplete views
+of those types would provide much benefit:-)
+
+This seems to be another argument against an approach along the lines of 'Ref
+(although one way out might be to define a full view for 'Ref types, but
+disallow use of any representation or operational attributes on them).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March  9, 2009  6:29 PM
+
+> This seems to be another argument against an approach along the lines
+> of 'Ref (although one way out might be to define a full view for 'Ref
+> types, but disallow use of any representation or operational
+> attributes on them).
+
+Right, but that means no storage pools for 'Ref types, which means no control
+over allocators. At which point, what's the point?? We've already got types with
+no control over allocators, and that supposedly is an important problem. Not
+solving it seems to be no help.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, March  9, 2009  7:05 PM
+
+I didn't mean to suggest that no aspect clauses could be given for them, rather
+that you couldn't use attributes of a 'Ref view that comes from a limited with.
+That would still allow storage pools, but disallow cases like in Steve's example
+where mutually dependent types share a storage pool.  Anyway, maybe that
+limitation plus the fact that these couldn't be used as generic actuals, as
+pointed out by Steve, would be too odd and restrictive.  It was just a thought.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March  9, 2009  7:241 PM
+
+Umm, I thought I was the one with the flu who is dizzy. :-) How would you write
+an allocator for a 'Ref imported from a limited view if you don't know the
+storage pool? How would you generate code for an assignment/parameters passing
+if you don't know the Convention, 'Size, etc.? I don't see how you could
+generate any code in those circumstances.
+
+The only way to make that work would be to ensure that 'Ref always had the same
+representation, convention, etc. Which would be really limiting. (I suppose you
+could ban allocators, generic matching, and stream attributes for such a type
+imported from a limited view, and just require the representation and convention
+to match exactly. But that too seems limiting - and hardly any different than
+what anonymous type already offer.)
+
+> Anyway, maybe that limitation plus the fact that these couldn't be
+> used as generic actuals, as pointed out by Steve, would be too odd and
+> restrictive.  It was just a thought.
+
+Right.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, March  9, 2009  7:28 PM
+
+> I didn't mean to suggest that no aspect clauses could be given for
+> them, rather that you couldn't use attributes of a 'Ref view that
+> comes from a limited with.  That would still allow storage pools, but
+> disallow cases like in Steve's example where mutually dependent types
+> share a storage pool.  Anyway, maybe that limitation plus the fact
+> that these couldn't be used as generic actuals, as pointed out by
+> Steve, would be too odd and restrictive.  It was just a thought.
+
+Even if you somehow disallowed explicit queries of problematic attributes, Size
+and Alignment would be a problem.
+
+Consider
+
+    limited with Some_Package;
+    package Pkg is
+       subtype Ref is Some_Package.Some_Type'Ref;
+       type Ref_Vector is array (Character) of Ref;
+    end Pkg;
+
+and then you start asking awkward questions about representation attributes of
+Ref_Vector (Size, Alignment, Component_Size), etc.
+
+Or you just start doing things which implicitly depend on these values (e.g.,
+declare an object and then access components thereof).
+
+Or you refer to Streaming attributes of Ref_Vector.
+
+****************************************************************
+========= One message with no on-topic discussion ===========
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, March 12, 2009  10:02 AM
+
+I would like to suggest in our upcoming subcommittee meeting on anon access
+types (and we have another topic too I think) that we distinguish what represent
+fixes to Ada 2005 from what represent extensions.
+
+I think I agree with Bob that we don't want to start adding extensions if we
+don't think they provide an overall solution to some essential problems. On the
+other hand, I believe we *should* make fixes to existing Ada 2005 features even
+if they are only "incremental" improvements.
+
+I am happy to talk about some cool futuristic ideas for making anonymous access
+types more useful, but I really want to agree and propagate fixes to what we
+believe is broken in Ada 2005.
+
+To be specific, I would like to spend some time talking first talking about
+local stand-alone objects of an anonymous access type and about access results,
+which I believe are the two areas of Ada 2005 that are broken.  I will write up
+a proposal for locals, based on the series of e-mails I sent out earlier in
+response to Franco's reverse-the-list challenge.  For access results, I would
+like to use AI-51 as the starting point.
+
+By the way, another way to view the AI-51 access result proposal is that it is
+essentially proposing to follow the build-in-place model for access results when
+the result is defined by an anonymous allocator.
+
+A related way to think about it is to imagine if the result type were T'Class.
+In that case, the result object might have coextensions (even if T itself
+doesn't have any access discriminants, some extension of T might).  We would use
+context to determine where such coextensions would be allocated. Access results
+should be analogous to that, where if the return expression is an anonymous
+allocator, then it should be treated analogously as far as determining the
+storage pool.
+
+I hope these analogs help.  If they don't, then just read AI-51... ;-)
+
+*After* we agree whether and what fixes to make to Ada 2005, then I would be
+happy to talk about possible extensions. Until we come up with fixes, I think it
+is premature to even identify what problems remain that are worth solving. I
+really don't want to get bogged down in talking about extensions and leave Ada
+2005 clearly broken.
+
+And by the way, what was the other topic?  The aspect specification idea?
+Conditional expressions and/or "implies"?  I can't remember.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent