CVS difference for ais/ai-00254.txt

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

--- ais/ai-00254.txt	2005/08/05 04:33:04	1.23
+++ ais/ai-00254.txt	2005/10/31 05:18:18	1.24
@@ -1160,7 +1160,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: 2005/08/05 04:33:04 $ $Revision: 1.23 $
+!from Bob Duff $Date: 2005/10/31 05:18:18 $ $Revision: 1.24 $
 !discussion
 
 Two issues related to access types and the accessibility rules came
@@ -1573,7 +1573,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: 2005/08/05 04:33:04 $ $Revision: 1.23 $
+!from Bob Duff $Date: 2005/10/31 05:18:18 $ $Revision: 1.24 $
 !discussion
 
 This Language Study Note discusses accessibility checks, and their
@@ -4311,3 +4311,666 @@
 is a long time.
 
 ****************************************************************
+
+From: Dan Eilers
+Sent: Monday, April 11, 2005  6:40 PM
+
+Back in January, there was a discussion about the drawbacks of
+the currently proposed syntax for anonymous access type parameters.
+The consensus seemed to be that the current syntax is ugly, but
+no better proposal was available.
+
+I experimented recently with an 8-queens demo program that had
+been posted to c.l.a. by Brian Rogoff on Sep 9 1999, which was
+written in a functional-programming style using the implementation-defined
+Unrestricted_Access attribute.  I converted it to portable Ada 2005,
+but the conversion was quite painful.
+
+In the original, type Cont_Proc_Type was used (and therefore had to be
+replicated) 5 times, including as a parameter to type Gen_Proc_Type.
+
+So the reasonable looking original:
+    procedure Doo(N    : Integer;
+                  Gen  : Gen_Proc_Type;
+                  Cont : Cont_Proc_Type;
+                  L    : List_Type ) is
+
+
+got changed to the messy:
+
+    procedure Doo(N    : Integer;
+                  Gen  : access procedure (Cont :
+                                           access procedure (L : in List_Type);
+                                           L : in List_Type);
+                  Cont : access procedure (L : in List_Type);
+                  L    : List_Type ) is
+
+
+If this procedure had been in a package spec, it would have been even worse,
+since it would have had to be duplicated in the body.
+
+This seems contrary to the Ada style where parameter types are
+simple names, where for example string(1..10) is not allowed.
+
+So here's a proposed solution.  Piggy-back on the existing syntax
+for named subprogram access types, and allow the keyword "limited"
+as a modifier in a formal-parameter list, to mean the parameter
+isn't allowed to be copied.
+
+So instead of:
+
+    procedure Doo(N    : Integer;
+                  Gen  : access procedure (Cont :
+                                          access procedure (L : in List_Type);
+                                            L : in List_Type);
+                  Cont : access procedure (L : in List_Type);
+                  L    : List_Type ) is
+
+we would have:
+
+    procedure Doo(N    : Integer;
+                  Gen  : Limited Gen_Proc_Type;         -- limited added
+                  Cont : Limited Cont_Proc_Type;        -- limited added
+                  L    : List_Type ) is
+
+
+Then, converting from Ada95 to Ada2005 involves only changing
+'Unrestricted_Access to 'Access, and adding "limited" to the
+corresponding formal parameter lists.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, April 11, 2005  6:56 PM
+
+>     procedure Doo(N    : Integer;
+>                   Gen  : Limited Gen_Proc_Type;         -- limited added
+>                   Cont : Limited Cont_Proc_Type;        -- limited added
+>                   L    : List_Type ) is
+
+Sounds like the limited access types proposal from days of yore.
+
+I see why the 8-queens thing might need a lot of duplication using the
+current syntax, but I suspect *most* uses of this feature are things
+like iterators, where you don't really need or want a named type;
+it's a benefit to make it anonymous.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, April 11, 2005  8:55 PM
+
+For historical reference, we had limited access types
+early in the Ada 9X process, for essentially this
+purpose.  We abandoned it because of the various
+scattered assumptions that limited types were composite.
+
+In your proposal, you are actually not defining
+a new type, but rather defining a characteristic
+of the parameter object, analogous to constantness.
+However, accessibility rules generally are associated with
+the type as opposed to the object, and clearly these parameters
+have different accessibility properties.  Having
+accessibility reside with the object rather than
+the type might require some serious surgery on
+an already fragile part of the manual, FWIW.
+
+But of course the important issue is whether this
+change is desirable.  The general notion of an
+uncopyable object is interesting, but having it
+just in this one context would be disturbing.
+I fear it opens an albeit interesting can of worms
+that is just too interesting given the current
+state of the amendment process.  Perhaps revisit
+for 2015?
+
+****************************************************************
+
+From: Florian Weimer
+Sent: Tuesday, April 12, 2005  7:00 AM
+
+* Dan Eilers:
+
+> This seems contrary to the Ada style where parameter types are
+> simple names, where for example string(1..10) is not allowed.
+
+On the other hand, repetition of subprogram profiles is already common
+in Ada, in generic formal subprograms.  I'm no longer sure if the
+redundancy in anonymous access-to-subprogram parameter declarations is
+a real issue.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Tuesday, April 12, 2005  3:25 PM
+
+Bob Duff wrote:
+> Sounds like the limited access types proposal from days of yore.
+
+Yes, it is sort of a hybrid of the two previous proposals,
+retaining the conciseness of the limited-access-type proposal,
+but without the complexity of introducing a new kind of type.
+It also retains the language consistency of the limited-access-type
+proposal, using "limited" to mean no assignment, rather than
+using the hack of type anonymity to prevent assignment.
+
+> I see why the 8-queens thing might need a lot of duplication using the
+> current syntax, but I suspect *most* uses of this feature are things
+> like iterators, where you don't really need or want a named type;
+> it's a benefit to make it anonymous.
+
+Ada has a long history of not quite fully coming to grips with the
+intended uses of subprograms as parameters to other subprograms.
+In Ada83, it was suspected that most of the uses of this feature
+would be satisfied by generic formal subprogram parameters, and that
+it would be a benefit that instantiations would be static.  But as
+a consequence, Ada83 was not ideally suited to the era of bit-mapped
+windowing systems which relied heavily on callbacks.
+
+In Ada95, it was suspected that most of the remaining uses of
+this feature would be satisfied by named subprogram access types,
+and that they would benefit from C-compatibility by not needing
+to carry static links.  But as a consequence, Ada95 was not ideally
+suited to the era of container libraries, which relied heavily on
+iterators needing access to up-level scopes.
+
+In Ada2005, it is suspected that most of the remaining uses of
+this feature will be satisfied by one-off simple cases where
+indirectly-called subprograms have very few parameters, none of which
+are themselves indirectly-called subprograms.   But grepping the
+AI-302 container package on Matthew Heaney's web site shows 64
+occurrences of "access procedure (Position : in Cursor)", so there
+is already considerable redundancy that could be avoided even
+for iterators, not to mention for functional-style programming.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 12, 2005  4:05 PM
+
+...
+> Ada has a long history of not quite fully coming to grips with the
+> intended uses of subprograms as parameters to other subprograms.
+
+You mean software developers have never come to grips with the fact that
+subprograms as parameters is almost never the best solution to any problem,
+and thus they use them in all kinds of tricky ways. Ada rightly has not
+attempted to support such tricks, and thus has been pilloried for it. But
+the problem is with the people trying to use those tricks, not with Ada.
+
+...
+> In Ada95, it was suspected that most of the remaining uses of
+> this feature would be satisfied by named subprogram access types,
+> and that they would benefit from C-compatibility by not needing
+> to carry static links.  But as a consequence, Ada95 was not ideally
+> suited to the era of container libraries, which relied heavily on
+> iterators needing access to up-level scopes.
+
+Huh? The problem is that Ada doesn't have real iterators. The use of a
+subprogram to represent one is so heavywight and syntactically clunky that
+only machocists will do it. (I tried to write the Claw Builder in that
+style, and I've regretted it ever since. And the problems have little to do
+with up-level access.)
+
+> In Ada2005, it is suspected that most of the remaining uses of
+> this feature will be satisfied by one-off simple cases where
+> indirectly-called subprograms have very few parameters, none of which
+> are themselves indirectly-called subprograms.   But grepping the
+> AI-302 container package on Matthew Heaney's web site shows 64
+> occurrences of "access procedure (Position : in Cursor)", so there
+> is already considerable redundancy that could be avoided even
+> for iterators, not to mention for functional-style programming.
+
+We've discussed this before: the profiles are similar because we made a
+concerted effort to keep things as close as possible. But "Cursor" means
+something different in each package, and there are never more than two such
+subprograms in a package spec, so there is virtually no gain from having a
+name for the type. Just because things are lexically the same doesn't mean
+that they are the same!
+
+In any case, overuse of access-to-subprograms shows bad design IMHO. If Ada
+had real iterators, I would never use them other than in interfacing code.
+I'm glad the syntax is ugly, because it will help to convince people to look
+for better solutions (and perhaps invent a proper iterator for Ada). I
+didn't want anonymous access-to-subprograms in the first place, and I
+certainly didn't want the iterators in the containers library to use any
+sort of access-to-subprograms.
+
+In any case, a limited elementary type is something I would have liked to
+see, but there wasn't enough interest. And a modifier is a non-starter,
+given that it would violate just about every invariant that exists in Ada.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Tuesday, April 12, 2005  5:23 PM
+
+Randy wrote:
+> In any case, a limited elementary type is something I would have liked to
+> see, but there wasn't enough interest. And a modifier is a non-starter,
+> given that it would violate just about every invariant that exists in Ada.
+
+I'm not sure what invariants you are referring to.
+Presumably they are not semantic invariants, because my
+proposal has the same semantics as the current proposal.
+If you are talking about syntactic invariants, my proposal
+has the advantage over the current proposal of not violating
+the invariant that parameter types are simple-names, involving
+no arbitrarily deeply nested constructs.
+
+> We've discussed this before: the profiles are similar because we made a
+> concerted effort to keep things as close as possible. But "Cursor" means
+> something different in each package, and there are never more than two such
+> subprograms in a package spec, so there is virtually no gain from having a
+> name for the type. Just because things are lexically the same doesn't mean
+> that they are the same!
+
+It seems unfortunate that the only commonality that was factored out
+between the different container packages was Hash_Type and Count_Type.
+"Cursor" certainly means essentially the same thing in each package.
+
+But even as it stands, with 2 subprograms in each spec and 2 more copies
+in each body, that is 4 copies per package that could be replaced with a
+single type declaration.
+
+> I'm glad the syntax is ugly, because it will help to convince people to look
+> for better solutions (and perhaps invent a proper iterator for Ada).
+
+I haven't seen the draft Ada 2005 rationale yet.  Is it really going to
+say something to the effect that the new Ada 2005 syntax is intentionally
+ugly so that Ada 2005 customers will demand proper iterators in a future
+version of the language?  I certainly don't see anything to that effect
+in the draft RM introduction.  Potential compiler customers who are
+interested in particular language features generally aren't impressed
+to hear that their favorite feature is intentionally ugly and no better
+alternative is available.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 12, 2005  7:07 PM
+
+Dan wrote:
+
+> Randy wrote:
+> > In any case, a limited elementary type is something I would have liked to
+> > see, but there wasn't enough interest. And a modifier is a non-starter,
+> > given that it would violate just about every invariant that
+> exists in Ada.
+>
+> I'm not sure what invariants you are referring to.
+> Presumably they are not semantic invariants, because my
+> proposal has the same semantics as the current proposal.
+
+Absolutely not. Your proposal adds a subtypey modifier (like "not null") to
+an existing type to change the (deep) semantics (include the representation,
+whether it can be copied, its accessibility level, etc.) of the type. The
+existing proposal hangs that stuff on a new kind of type, for which the deep
+differences are not as much of a concern.
+
+> If you are talking about syntactic invariants, my proposal
+> has the advantage over the current proposal of not violating
+> the invariant that parameter types are simple-names, involving
+> no arbitrarily deeply nested constructs.
+
+There is no such invariant in Ada 95. Anonymous access types are allowed in
+subprograms, and they're not "simple-names" unless you look at them
+upside-down. And there is even less of one in Ada 2005, even without this
+feature, since "not null" is allowed on parameters. And "constant" is
+allowed in anonymous access types. We even looked at allowing full
+subtype_indications, but there are problems with elaboration and conformance
+checking.
+
+Now, I happen to think the entire anonymous access type thing was a mistake.
+But that genie is long out of the bottle, and it can't be put back in.
+
+> > We've discussed this before: the profiles are similar because we made a
+> > concerted effort to keep things as close as possible. But "Cursor" means
+> > something different in each package, and there are never more than two such
+> > subprograms in a package spec, so there is virtually no gain from having a
+> > name for the type. Just because things are lexically the same doesn't mean
+> > that they are the same!
+>
+> It seems unfortunate that the only commonality that was factored out
+> between the different container packages was Hash_Type and Count_Type.
+> "Cursor" certainly means essentially the same thing in each package.
+
+Not at all. A "cursor" is an abstract reference to an element of some type.
+These are strongly typed, so that you can't mix cursors that point at
+Integers with cursors that point at Storage_Pools. Without that typing, you
+would need extra runtime checks to insure that the correct kind of item is
+pointed at, and many more mistakes would not be detected until runtime. It's
+always better to detect errors at compile-time when you can.
+
+> But even as it stands, with 2 subprograms in each spec and 2 more copies
+> in each body, that is 4 copies per package that could be replaced with a
+> single type declaration.
+
+No one should be reading the bodies of these routines.
+
+> > I'm glad the syntax is ugly, because it will help to convince people to look
+> > for better solutions (and perhaps invent a proper iterator for Ada).
+>
+> I haven't seen the draft Ada 2005 rationale yet.  Is it really going to
+> say something to the effect that the new Ada 2005 syntax is intentionally
+> ugly so that Ada 2005 customers will demand proper iterators in a future
+> version of the language?
+
+I doubt it, because the author was the major proponent of this abmination.
+
+And in any case, you're mixing up my personal opinions (which I clearly
+marked by saying "I"!!) with those regarding the Ada standard.
+
+> I certainly don't see anything to that effect
+> in the draft RM introduction.  Potential compiler customers who are
+> interested in particular language features generally aren't impressed
+> to hear that their favorite feature is intentionally ugly and no better
+> alternative is available.
+
+If that's their favorite feature, I'd suggest that they go back and learn
+software engineering. The point of Ada is to do things the right way, not
+the easy or tricky way. Way too many junky designs are copied from other
+languages rather than writing a good one. Explicit use of access types
+(outside of the low-level implementation of an abstraction) is almost always
+in that category. And that is my *personal* opinion, not one necessarily
+held by any group that is working on the Ada standard.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Tuesday, April 12, 2005  7:58 PM
+
+Randy wrote:
+> > I'm not sure what invariants you are referring to.
+> > Presumably they are not semantic invariants, because my
+> > proposal has the same semantics as the current proposal.
+>
+> Absolutely not. Your proposal adds a subtypey modifier (like "not null") to
+...
+
+My proposal is purely syntactic.  It has absolutely no semantic
+component to it at all.  I am proposing to simply change the syntax
+of parameter specifications from:
+
+        x: access procedure p(...);
+
+to
+
+        type foo is access procedure p(...);
+        x: limited foo;
+
+If you like, you can think of "limited foo" as creating an anonymous
+access to subprogram type, exactly as in the current proposal.
+Or you can think of "limited" as modifying the parameter x
+instead of modifying the type foo.
+
+> > If you are talking about syntactic invariants, my proposal
+> > has the advantage over the current proposal of not violating
+> > the invariant that parameter types are simple-names, involving
+> > no arbitrarily deeply nested constructs.
+>
+> There is no such invariant in Ada 95. Anonymous access types are allowed in
+....
+
+Well, I was ignoring the modifiers allowed in parameter specifications
+(In, Out, In Out, Access, Constant, and Not Null).  Modulo those,
+parameter types are simple names in Ada.
+
+> Not at all. A "cursor" is an abstract reference to an element of some type.
+> These are strongly typed, so that you can't mix cursors that point at
+> Integers with cursors that point at Storage_Pools.
+
+I agree that they should be strongly typed, but it's unfortunate that
+the requirement that they be strongly typed precludes taking advantage
+of their commonality, i.e., that they are a record with two fields,
+a Container and a Node or Index, and are used in common operations
+such as Iterate and Reverse_Iterate.
+
+
+> > But even as it stands, with 2 subprograms in each spec and 2 more copies
+> > in each body, that is 4 copies per package that could be replaced with a
+> > single type declaration.
+>
+> No one should be reading the bodies of these routines.
+
+The issue isn't who should be reading what.  The issue is whether
+or not the current syntax is the best we can do.  The AI-302
+packages are only used as an example where naming the anonymous
+subprogram access type would simplify the code.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, April 12, 2005  7:43 PM
+
+Dan wrote:
+
+> Bob Duff wrote:
+> > Sounds like the limited access types proposal from days of yore.
+>
+> Yes, it is sort of a hybrid of the two previous proposals,
+> retaining the conciseness of the limited-access-type proposal,
+> but without the complexity of introducing a new kind of type.
+> It also retains the language consistency of the limited-access-type
+> proposal, using "limited" to mean no assignment, rather than
+> using the hack of type anonymity to prevent assignment.
+>
+> > I see why the 8-queens thing might need a lot of duplication using the
+> > current syntax, but I suspect *most* uses of this feature are things
+> > like iterators, where you don't really need or want a named type;
+> > it's a benefit to make it anonymous.
+>
+> Ada has a long history of not quite fully coming to grips with the
+> intended uses of subprograms as parameters to other subprograms.
+
+Indeed.
+
+> In Ada83, it was suspected that most of the uses of this feature
+> would be satisfied by generic formal subprogram parameters, and that
+> it would be a benefit that instantiations would be static.  But as
+> a consequence, Ada83 was not ideally suited to the era of bit-mapped
+> windowing systems which relied heavily on callbacks.
+>
+> In Ada95, it was suspected that most of the remaining uses of
+> this feature would be satisfied by named subprogram access types,
+> and that they would benefit from C-compatibility by not needing
+> to carry static links.  But as a consequence, Ada95 was not ideally
+> suited to the era of container libraries, which relied heavily on
+> iterators needing access to up-level scopes.
+
+Well, I strongly pushed for downward (inward) closures in Ada 9X.
+I lost.  I'm just glad Ada 2005 is finally catching up to Pascal in this
+regard.  Yeah, the syntax could be better, but I'm not inclined to rock
+the boat at this point.  If I have to say "not null access procedure
+blah blah blah", which is ugly, well at least I can do it.
+What I *really* want, syntax-wise, would be the ability to pass that
+parameter anonymously, a la Lisp's lambda.  We ain't gonna git that!
+
+> In Ada2005, it is suspected that most of the remaining uses of
+> this feature will be satisfied by one-off simple cases where
+> indirectly-called subprograms have very few parameters, none of which
+> are themselves indirectly-called subprograms.   But grepping the
+> AI-302 container package on Matthew Heaney's web site shows 64
+> occurrences of "access procedure (Position : in Cursor)", so there
+> is already considerable redundancy that could be avoided even
+> for iterators, not to mention for functional-style programming.
+
+I think Randy answered this point.  There's not much redundancy,
+when you consider the types.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Tuesday, April 12, 2005  8:23 PM
+
+> What I *really* want, syntax-wise, would be the ability to pass that
+> parameter anonymously, a la Lisp's lambda.  We ain't gonna git that!
+
+How come you don't want curried functions?
+
+> I lost.  I'm just glad Ada 2005 is finally catching up to Pascal in this
+> regard.  Yeah, the syntax could be better, but I'm not inclined to rock
+> the boat at this point.  If I have to say "not null access procedure
+> blah blah blah", which is ugly, well at least I can do it.
+
+Yes, it's nice to finally be able to do this.  But coincidentally
+a SIGAda 2005 call for papers came today, and it would have been
+nice to be able to show off this new feature with the queens demo.
+But it's just too ugly to show. :(
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 12, 2005  8:29 PM
+
+Dan wrote:
+
+> Randy wrote:
+> > > I'm not sure what invariants you are referring to.
+> > > Presumably they are not semantic invariants, because my
+> > > proposal has the same semantics as the current proposal.
+> >
+> > Absolutely not. Your proposal adds a subtypey modifier (like
+> "not null") to
+> ...
+>
+> My proposal is purely syntactic.
+
+There is no such thing. You have to define what the meaning of that syntax
+is.
+
+> It has absolutely no semantic
+> component to it at all.  I am proposing to simply change the syntax
+> of parameter specifications from:
+>
+>         x: access procedure p(...);
+>
+> to
+>
+>         type foo is access procedure p(...);
+>         x: limited foo;
+>
+> If you like, you can think of "limited foo" as creating an anonymous
+> access to subprogram type, exactly as in the current proposal.
+
+Then it isn't semantically the same, because here you would have *two* type
+declarations. And you'd still have to problem of picking a good name for a
+one-time use access type.
+
+> Or you can think of "limited" as modifying the parameter x
+> instead of modifying the type foo.
+
+Which makes no sense at all. The representation of X would have no
+resemblance to the representation of Foo at all; that's one of the
+invariants that would be totally trashed.
+
+...
+> > Not at all. A "cursor" is an abstract reference to an element of some type.
+> > These are strongly typed, so that you can't mix cursors that point at
+> > Integers with cursors that point at Storage_Pools.
+>
+> I agree that they should be strongly typed, but it's unfortunate that
+> the requirement that they be strongly typed precludes taking advantage
+> of their commonality, i.e., that they are a record with two fields,
+> a Container and a Node or Index, and are used in common operations
+> such as Iterate and Reverse_Iterate.
+
+They won't be a record with "two fields" in my implementation. But that's
+not particularly relevant. The main property of a cursor is that it
+designates an element of some type in some sort of container, and it would
+be hard to abstract that.
+
+I looked at trying to use interface types with containers to encapsulate the
+commonality, but they have the same problem: you have to know the element
+type in order to be able to do anything interesting. And that makes it very
+hard to have any sort of commonality.
+
+It's the nature of the strong, static typing of Ada. You'd have to have a
+more dynamic type model to get any more commonality out of these operations.
+(You sort of can do this on your own by declaring containers holding
+Ada.Finalization.Controlled'Class, which is the basis of many types in Ada
+95 programs. But then you don't need any interfaces; just use your
+instantiation for commonality.)
+
+> > > But even as it stands, with 2 subprograms in each spec and 2 more copies
+> > > in each body, that is 4 copies per package that could be replaced with a
+> > > single type declaration.
+> >
+> > No one should be reading the bodies of these routines.
+>
+> The issue isn't who should be reading what.
+
+Of course it is. The only issue here is whether the syntax is good enough,
+and that is solely a readability issue. You're not suggesting any change in
+semantics.
+
+> The issue is whether
+> or not the current syntax is the best we can do.  The AI-302
+> packages are only used as an example where naming the anonymous
+> subprogram access type would simplify the code.
+
+I disagree with the notion that your proposed syntax would "simplify" the
+specifications of the container packages. You'd add one extra type to each
+package, and an extra name to understand, in order to replace 8 tokens
+("access procedure (Position : in Cursor)") with 2 ("limited Something").
+The package would be a bit more complicated, so I don't think that there
+would be any net gain.
+
+It might simplify the bodies a tiny bit, but that hardly matters, since the
+bodies will be huge and saving 12 tokens is an insignificant part of the
+total.
+
+I don't doubt that there exists some example where some other syntax would
+be better. That's true for virtually every choice of syntax in Ada. The
+question is whether there are enough such examples to make the exercise
+worthwhile. Nobody has been convinced to this point. Perhaps that will
+change with experience. We have to leave something to do in 2015, right??
+:-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 12, 2005  9:29 PM
+
+I wrote:
+
+...
+> Huh? The problem is that Ada doesn't have real iterators. The use of a
+> subprogram to represent one is so heavyweight and syntactically clunky that
+> only machocists will do it. (I tried to write the Claw Builder in that
+> style, and I've regretted it ever since. And the problems have
+> little to do with up-level access.)
+
+In case anyone is thinking I've lost my mind (which I suppose is possible),
+I think an Ada iterator should look something like a for loop. Something
+like:
+
+    for E in My_Container loop
+        -- Use E here.
+    end loop;
+
+This of course allows early exits and reverse traversal in a natural way.
+
+There would need to be some way to define the definition of an iterator for
+a particular element type. One possibility would be follow the lead of
+Controlled types and Storage_Pools, and declare a magic root package with
+the needed operations.
+
+Or some special attribute that can be defined might do the trick. (But it
+probably would make sense to have two or three operations, as startup and
+cleanup probably need to be handled separately. So an attribute wouldn't be
+real clean.)
+
+The need to separately define a procedure to do part of the job is
+unnatural, confusing, and requires writing a lot of extra stuff that has
+nothing to do with the problem. It is separated from its use, and inside
+out. Something that looks like whats really going on would be preferable. It
+also has the advantage of reinforcing that these are "safe" uses (for loops
+being the only "safe" loops, in that you don't have to explicitly terminate
+them).
+
+It's too late to do this properly this time, of course, and I don't think it
+would have been important enough to do anyway.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent