CVS difference for ais/ai-00254.txt

Differences between 1.18 and version 1.19
Log of other versions for file ais/ai-00254.txt

--- ais/ai-00254.txt	2004/12/09 19:55:22	1.18
+++ ais/ai-00254.txt	2005/01/28 02:10:40	1.19
@@ -1147,7 +1147,7 @@
 !reference RM9X-3.10.2(16);4.0
 !reference AARM-12.3(12.p,12.q);4.0
 !reference LSN-1042 on Accessibility Checks in Generics
-!from Bob Duff $Date: 2004/12/09 19:55:22 $ $Revision: 1.18 $
+!from Bob Duff $Date: 2005/01/28 02:10:40 $ $Revision: 1.19 $
 !discussion
 
 Two issues related to access types and the accessibility rules came
@@ -1560,7 +1560,7 @@
 !topic LSN on Accessibility Checks in Generics
 !key LSN-1042 on Accessibility Checks in Generics
 !reference MS-12;4.6
-!from Bob Duff $Date: 2004/12/09 19:55:22 $ $Revision: 1.18 $
+!from Bob Duff $Date: 2005/01/28 02:10:40 $ $Revision: 1.19 $
 !discussion
 
 This Language Study Note discusses accessibility checks, and their
@@ -3995,4 +3995,306 @@
 
 ****************************************************************
 
+!topic Named anonymous access types
+!reference AI95-00254
+!from Adam Beneschan 05-01-12
+!discussion
+
+This may be a minor point (and perhaps someone else has made this
+point in the past), but now that you can declare a subprogram
+parameter to have an anonymous access-to-subprogram (AATS) type, I'm
+wondering whether it makes sense to figure out a way to give names to
+such types.  My concerns are that (1) a subprogram declaration that
+contains, say, five parameters, two of which have AATS types that
+contain three more parameters each, can start getting awfully
+cluttered and difficult to read; and, perhaps more importantly, (2) if
+a package specification contains many subprograms that all have
+parameters with equivalent AATS types, and there's a design change
+that requires all of those AATS types to be changed in the same way
+(perhaps by adding an extra parameter), the change must be made in
+many places instead of just one.
+
+My proposal is to have a way to declare a named anonymous access type,
+e.g.
+
+ type Float_Function is anonymous access function (X : Float) return Float;
+
+that declares Float_Function to be an anonymous access-to-function
+type.  Then, the name Float_Function could appear anywhere an
+anonymous access type could appear (as a subprogram parameter type, or
+as a discriminant or component type).  It could *not* be used anywhere
+else.  You couldn't declare an object of this type, it couldn't be
+used as the target of a type conversion, etc.  The rules for
+accessibility checks would be the same as for any anonymous access
+type.  I believe that if such a name would be usable *only* where an
+anonymous access type is usable, there wouldn't be any substantial
+change in the Static Semantics or Dynamic Semantics anywhere in the
+language; essentially, the name would be sort of like a macro.
+Implementing such a proposal shouldn't be too difficult.
+
+Of course, the !topic name is a joke, and so is the proposed syntax,
+since something that has a name is not anonymous.  If we do something
+like this, we'd probably have to come up with another term for
+"anonymous" access types besides "anonymous".  This makes sense to me
+anyway, since the important feature of "anonymous" access types (and
+the reason one would want to use them) is that the fact that
+accessibility level checking is different than it is for "named"
+access types (3.10.2(12-13), etc.), not the fact that they don't have
+names.
+
+****************************************************************
+
+From: Marius Amado Alves
+Sent: Wednesday, January 12, 2005  5:51 PM
+
+> ... If we do something
+> like this, we'd probably have to come up with another term for
+> "anonymous" access types besides "anonymous".
+
+"Unchecked" ?
+
+> This makes sense to me
+> anyway, since the important feature of "anonymous" access types (and
+> the reason one would want to use them) is that the fact that
+> accessibility level checking is different than it is for "named"
+> access types (3.10.2(12-13), etc.), not the fact that they don't have
+> names.
+
+Named unchecked types sound useful, but somehow I always worry about
+adding a new keyword to the language. How about
+
+    type My_Function renames access function...
+
+****************************************************************
+
+From: Christoph Grein
+Sent: Thursday, January 13, 2005  1:30 AM
+
+ > Named unchecked types sound useful, but somehow I always worry about
+ > adding a new keyword to the language. How about
+ >
+ >     type My_Function renames access function...
+
+This reflects exactly my feeling since I know this terrible syntax from
+Pascal
+(the language, not the other Pascal around here :-) I used a bit before
+Ada came
+around.
+
+I'm sure someone in ARG could come up with a nice syntax. As it stands,
+AI95-00254 is no good wrt syntax.
+
+Just for brainstorming: What about using the box <>?
+
+     type My_Func is access function ... is <>;
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, January 13, 2005  2:22 AM
+
+The ARG gave careful consideration to "named subtypes of anonymous access
+types", mainly in the context of access-to-object types.  Although this
+sounds superficially like a good idea, there are considerable semantic
+difficulties, and we gave up on that concept fairly early, because it was
+threatening to kill all the improvements to access types that we were
+considering.  I suggest that you read the minutes of the ARG meetings
+starting with the May 2001 meeting in Leuven, especially the part related
+to AI 230.
+
+First, note that there are two distinct kinds of anonymous access types in
+Ada 2005: those that have "normal" accessibility rules, and can be
+simulated by writing an explicit type declaration at the right place
+(e.g., anonymous access types used as components); and those that have
+"magic" accessibility rules that cannot be simulated by an explicit type
+declaration.  Only access parameters and access discriminants fall into
+the latter category.  Your proposal would only be useful for that
+category.
+
+As you point out, there would have to be numerous restrictions on the
+legal usages of such a type.  Instead of having the normal semantics of
+defining a set of values and a set of operations, the type name would be
+merely a shorthand for the designated profile.  This would be very
+inconsistent with the rest of the language.  In the odd case where you
+have 18 anonymous access-to-subprogram types that need to have the same
+profile, use a macro-processor: there is no justification in adding warts
+to the language for such a rare situation.  In other words, don't call it
+a type unless it walks like a type and quacks like a type.
+
+And of course, making this a true type wouldn't work: it would lead to an
+entire slew of contract model violations both for private types and for
+generics, because so many usages of the name would have to be forbidden.
+When we want to prevent users from using the type name in contexts where
+it would be problematic, well, we use anonymous types...
+
+Finally, no point in discussing the syntax ad nauseam as long as someone
+cannot come up with well-defined semantics.
+
+****************************************************************
+
+From: Marius Amado Alves
+Sent: Thursday, January 13, 2005  5:15 AM
+
+> Finally, no point in discussing the syntax ad nauseam as long as someone
+> cannot come up with well-defined semantics.
+
+I must be terribly missing something because I find Adam's proposal
+perfectly well defined. Actually I think it improves the current state
+by making explicit the natural separation of checkedness vs. namedness.
+The standard should simply define the semantics of unchecked types and
+then provide two ways of expressing them: anonymous types and named
+unchecked types. What's the big deal?
+
+That said, I tend to agree that the number of situations requiring named
+unchecked types might be too small to justify yet another addition to
+the language.
+
+Certainly not a new keyword. Ada syntax is fun: my favorites so far are
+"renames" and the box :-)
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, January 13, 2005  7:47 AM
+
+Well, I think the syntax in AI-254 is fine as is.  Yes, it can be a
+bit verbose, but the scenario you outline above is rather rare.
+The vast majority of subprograms do *not* take access-to-subp
+as parameters.  Typically, you have a package with a type,
+and 10 or 20 subprograms, and maybe 1 or 2 of those is an iterator
+or some such.  And the "Action" procedure passed to the iterator
+takes approximately one parameter.
+
+After all, if you have 10 procedures whose profile is
+"(X: Integer; Y: Some_Type; Z: Mumble)", you have to write
+that out 10 times.  You don't get to say:
+
+    type My_Proc_Type is procedure (X: Integer; Y: Some_Type; Z: Mumble);
+
+    P1, P2, ..., P10: My_Proc_Type;
+
+> My proposal is to have a way to declare a named anonymous access type,
+> e.g.
+>
+>  type Float_Function is anonymous access function (X : Float) return Float;
+
+I think at this late date, proposals for change would need to have exact
+RM wording proposed.  I think if you try to turn "sort of like a macro"
+into RM-ese, it will turn out a *lot* more complicated than it seems.
+Pascal (the ARG chair, not the programming language;-)) pointed out some
+difficulities.  All the other named types are not at all like macros,
+and that sort of inconsistency would lead to a lot of RM verbiage.
+
+> Of course, the !topic name is a joke, and so is the proposed syntax,
+> since something that has a name is not anonymous.  If we do something
+> like this, we'd probably have to come up with another term for
+> "anonymous" access types besides "anonymous".  This makes sense to me
+> anyway, since the important feature of "anonymous" access types (and
+> the reason one would want to use them) is that the fact that
+> accessibility level checking is different than it is for "named"
+> access types (3.10.2(12-13), etc.), not the fact that they don't have
+> names.
+
+I agree with your reasoning here, for subprograms.  But for other anon
+access types, the point is by-structure type matching, not (just)
+accessibility level.
+
+It is perhaps unfortunate that Ada 95 chose to attach accessibility
+magic to anonymity. But Ada 05 has to live with that decision.
+
+(It's even more unfortunate that we can't make "not null" be the default!)
+
+P.S. Your joke about "anonymous named types" already exists!
+No Ada types have names.  "Anonymous type" does not mean
+"type without a name", but "type with no named subtypes".
+
+****************************************************************
 
+From: Robert A. Duff
+Sent: Thursday, January 13, 2005  7:49 AM
+
+> > ... If we do something
+> > like this, we'd probably have to come up with another term for
+> > "anonymous" access types besides "anonymous".
+>
+> "Unchecked" ?
+
+To me, "unchecked" would imply "might cause dangling pointers",
+as for Unchecked_Access and Unchecked_Deallocation.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 13, 2005  10:31 AM
+
+For what it's worth, early in the Ada 9X process
+we considered having "limited" access types,
+which ultimately became the anonymous access types.
+Limited access types didn't allow assignment,
+which thereby allowed them to have more flexible
+accessibility rules.  One reason we abandoned
+it, I believe, was that we also wanted the
+implicit conversion that anonymous access types
+support, and having implicit conversion to named
+(limited) types seemed like a violation of general
+Ada philosophy.
+
+****************************************************************
+
+From: Adam Beneschan
+Sent: Thursday, January 13, 2005  10:54 AM
+
+> I think at this late date, proposals for change would need to have exact
+> RM wording proposed.
+
+How do you figure ten years ahead of time to be a "late date"?  :) :)
+
+Seriously, I didn't mean to imply that this should be considered for
+Ada 2005---and I really did not expect that it would be considered for
+that.  I tend to comment about things as soon as I think about them.
+If this causes too much confusion, I could be persuaded to try to sit
+on them all until after Ada 2005 is finalized and then hopefully
+remember to post them later.
+
+Anyway, it might take some time to see whether your first
+objection---that the problem is rather rare---holds up.  You could be
+right, but it could be the case that when programmers start using
+downward closures that they may run into cases where it would be very
+helpful to add a name.  Matt Heaney's implementation of AI-302 does
+appear to contain many instances of anonymous access-to-procedure
+types with the same profile.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 13, 2005  12:05 PM
+
+> Matt Heaney's implementation of AI-302 does
+> appear to contain many instances of anonymous access-to-procedure
+> types with the same profile.
+
+But no more than two per package. The named type (if it existed) would have
+to be in each package, because it depends on the contents of the package or
+on the formal parameters. So having a name wouldn't gain much.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, January 13, 2005  7:24 PM
+
+> How do you figure ten years ahead of time to be a "late date"?  :) :)
+
+;-)
+
+> Seriously, I didn't mean to imply that this should be considered for
+> Ada 2005---and I really did not expect that it would be considered for
+> that.  I tend to comment about things as soon as I think about them.
+> If this causes too much confusion, I could be persuaded to try to sit
+> on them all until after Ada 2005 is finalized and then hopefully
+> remember to post them later.
+
+No, I don't think discussion of post-2005 changes needs to be
+squelched.  People might not pay too much attention, since > 10 years
+is a long time.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent