CVS difference for ais/ai-00230.txt

--- ais/ai-00230.txt	2000/04/14 03:39:47	1.1
+++ ais/ai-00230.txt	2000/05/17 20:49:06	1.2
@@ -502,3 +502,623 @@
 
 *************************************************************
 
+From: Christoph Grein
+Sent: Monday, May 08, 2000 11:45 PM
+Subject: [Ada-Comment] Predefined Access Types
+
+!topic Predefined Access Types
+!reference RM95-A.4.5(7,8), RM95-3.6.3, RM95-3.10
+!from Christoph Grein 2000-05-09
+!keywords access types, String_Access
+!discussion
+
+The type String_Access and corresponding function Free in A.4.5(7,8) seem
+misplaced in this package. They are not used there at all.
+
+In the light of the fact that when strings are handled, very often (I would even
+say, virtually always) an access type is also needed even if package
+Ada.Strings.Unbounded is not used, I would propose to shift these declarations
+to the place where type String is defined, 3.6.3. [And correspondingly for wide
+strings A.4.7.]
+
+This removes programmers' need to declare their own access types to strings all
+over the place.
+
+In a step further, I would propose a new 'Access attribute for types:
+Given any type T, T'Access would denote the following predefined general access
+type
+
+  type T'Access is access all T;
+
+This would be implicitly defined where T is defined. Correspondingly also the
+type T'Class'Access would be predefined where 'Class is defined.
+
+[There would have to be rule to prevent recursion: Since T'Access is also a
+type, T'Access'Access and so on should be ruled out as being predefined.]
+
+If this is accepted, the type String_Access can be defined as
+
+  subtype String_Access is String'Access;
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 09, 2000 6:31 PM
+To: 'Ada-Comment List'
+
+> In the light of the fact that when strings are handled, very often (I would
+> even say, virtually always) an access type is also needed even if package
+> Ada.Strings.Unbounded is not used, I would propose to shift these declarations
+> to the place where type String is defined, 3.6.3. [And correspondingly for
+> wide strings A.4.7.]
+
+This would be a very bad idea. Introducing names in Standard is *very*
+incompatible with existing code, as the names in Standard cannot be hidden, and
+would override any names currently accessible by a use clause.
+
+For instance, if a program contained:
+
+   package P is
+	type String_Access is access all My_String;
+   end P;
+
+   procedure M is
+	use P;
+      V : String_Access;
+      ...
+
+Your proposal would change V's type (silently!) from P.String_Access to
+Standard.String_Access. One place that would happen is for the declarations in
+Ada.Strings.Unbounded that started the discussion!
+
+Besides, your second proposal is a better way to accomplish the same thing
+without polluting Standard.
+
+> In a step further, I would propose a new 'Access attribute for types:
+> Given any type T, T'Access would denote the following
+> predefined general access type
+>
+>   type T'Access is access all T;
+
+This proposal looks rather attractive, but would be quite expensive on compilers
+hosted on memory-limited hosts. (Perhaps that doesn't matter anymore??)
+
+In any case, this exact proposal was made by Bob Duff in response to another
+proposal. I will attach your comment to that AI (AI-00230), because I don't want
+to spend anyone's time on the first proposal.
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Wednesday, May 10, 2000 10:14 AM
+
+> >   type T'Access is access all T;
+
+> This proposal looks rather attractive, but would be quite expensive on
+> compilers hosted on memory-limited hosts. (Perhaps that doesn't matter
+> anymore??)
+
+I'm not sure why it is expensive.  But I do think nobody should be
+running compilers on anything less than a 32-bit address space.
+(Target machines are often smaller, though.)
+
+> In any case, this exact proposal was made by Bob Duff in response to another
+> proposal.
+
+Actually, I think it was Robert Dewar's idea;
+I supported it.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, May 09, 2000 7:46 PM
+
+I strongly agree that introducing names into standard is a bad idea.
+
+As for type'Access, let's give credit where credit is due, I pushed this
+idea strongly during the design process, but it was rejected. note that
+the proposal in its current form is in any case incompatible with the
+current language design, which ascribes a quite different meaning top
+to type'Access in certain contexts.
+
+The objection to my proposal at the time was strong and clearly the majority
+viewpoint. The basis of this objection was that providing this distinguished
+anonymous type would tend to decrease type safety by encouraging the use of
+this type instead of properly typed access types. I see nothing that would
+change people's minds, and I think there is considerable merit in the majority
+viewpoint, so I see no argument for reopening this issue.
+
+By the way, the idea of putting this unreferenced type where it is was
+precisely to provide a standard string access type, does anyone use it
+this way?
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, May 10, 2000 11:44 AM
+
+> By the way, the idea of putting this unreferenced type where it is was
+> precisely to provide a standard string access type, does anyone use it
+> this way?
+
+I didn't even realize this type was in Ada.Strings.Unbounded until this
+comment, so for me at least, the answer is no.
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Wednesday, May 10, 2000 3:26 PM
+
+> I strongly agree that introducing names into standard is a bad idea.
+
+As Tuck is fond of pointing out, it's almost the same thing as adding a
+new reserved word to the language.
+
+> As for type'Access, let's give credit where credit is due, I pushed this
+> idea strongly during the design process, but it was rejected.
+
+Right.
+
+>... note that
+> the proposal in its current form is in any case incompatible with the
+> current language design, which ascribes a quite different meaning top
+> to type'Access in certain contexts.
+
+Heh?  What's type'Access?
+
+> The objection to my proposal at the time was strong and clearly the majority
+> viewpoint. The basis of this objection was that providing this distinguished
+> anonymous type would tend to decrease type safety by encouraging the use of
+> this type instead of properly typed access types. I see nothing that would
+> change people's minds, and I think there is considerable merit in the majority
+> viewpoint, so I see no argument for reopening this issue.
+
+I see no merit whatsoever in the majority viewpoint.  Most programs I've
+seen (or written) declare exactly one access type per designated type,
+right after the designated type is declared.  So in practise, people are
+*not* taking advantage of strongly typed access types.  Contrast this
+with (for example) integer types, where most programmers define a new
+integer type for each distinct purpose in the program.
+
+I think there *is* new information on the subject: people have realized
+from experience with Ada 95 that it's a big pain to have type
+conversions all over the place for perfectly safe cases (eg,
+access-to-T2'Class converted to access-to-T1'Class, where T2 is derived
+from T1, so conversions from T2'Class to T1'Class are of course
+implicit).  These bogus type conversions damage readability.  And part
+of the solution that has been discussed involves the T'Access idea.
+
+> By the way, the idea of putting this unreferenced type where it is was
+> precisely to provide a standard string access type, does anyone use it
+> this way?
+
+I doubt it.  Lots of programs don't use unbounded strings, so it
+wouldn't occur to the programmer to use this type.  But it's harmless,
+so no change is needed.  We're certainly not going to delete the type,
+and we're certainly not going to add a new type to package Standard.
+
+*************************************************************
+
+From: Gary Dismukes [dismukes@gnat.com]
+Sent: Wednesday, May 10, 2000 5:08 PM
+
+> >... note that
+> > the proposal in its current form is in any case incompatible with the
+> > current language design, which ascribes a quite different meaning top
+> > to type'Access in certain contexts.
+>
+> Heh?  What's type'Access?
+
+I'm guessing that Robert's referring to the case where the prefix
+is a current instance name (looks like a type name, though technically
+it's the name of an object of course).
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, May 10, 2000 7:48 PM
+
+Yup! That's what I was referring to, that is indeed the only context
+in which type'access can appear in the current language.
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Thursday, May 11, 2000 9:46 AM
+
+> > Heh?  What's type'Access?
+>
+> I'm guessing that Robert's referring to the case where the prefix
+> is a current instance name (looks like a type name, though technically
+> it's the name of an object of course).
+
+Isn't it *always* the name of the instance?  I mean, even if we chose to
+call it T'Pointer, we would have a problem, because the attribute would
+be unusable inside the type.  Not a big problem, but it would be
+annoying, because access types are quite often used to make
+self-referential record types.
+
+*************************************************************
+
+From: Robert Dewar [dewar@gnat.com]
+Sent: Thursday, May 11, 2000 3:47 AM
+To: ada-comment@ada-auth.org
+Subject: Re: [Ada-Comment] Predefined Access Types
+
+<<Where is T'Access defined? Oh - within record type definitions where it
+stands for the current instance of the type.>>
+
+Much more significantly, within tasks and protected objects to denote
+the current concurrent object.
+
+*************************************************************
+
+From: Gary Dismukes
+Sent: Thursday, May 11, 2000 1:34 PM
+
+> Isn't it *always* the name of the instance?  I mean, even if we chose to
+> call it T'Pointer, we would have a problem, because the attribute would
+> be unusable inside the type.  Not a big problem, but it would be
+> annoying, because access types are quite often used to make
+> self-referential record types.
+
+Yes, that's right, it will always denote the instance within the
+type, though I suppose that if a new attribute such as 'Pointer
+or whatever were used it could be defined to apply to the type
+of the object in the case of an object prefix, hmm.
+
+Anywya, as you say, the restriction within a type is annoying but
+doesn't seem like a major problem.  You could still use a workaround
+such as applying 'Access to a subtype name.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, May 10, 2000 7:52 PM
+
+<<Actually, I think it was Robert Dewar's idea;
+I supported it.>>
+
+Ah Bob, if you supported it, then you can't move for a reconsideration.
+To convince ourselves it is worth refighting this, we have to have at
+least one person change their minds :-)
+
+*************************************************************
+
+From: Christoph Grein
+Sent: Thursday, May 11, 2000 12:00 AM
+
+> I strongly agree that introducing names into standard is a bad idea.
+
+OK, I see the point.
+
+> .... note that
+> the proposal in its current form is in any case incompatible with the
+> current language design, which ascribes a quite different meaning top
+> to type'Access in certain contexts.
+
+RM K(2): P'Access where P denotes a subprogram
+RM K(4): X'Access where X denotes an object
+
+Where is T'Access defined? Oh - within record type definitions where it
+stands for the current instance of the type.
+
+
+> By the way, the idea of putting this unreferenced type where it is was
+> precisely to provide a standard string access type, does anyone use it
+> this way?
+>
+
+No, I dislike the idea of withing Strings.Unbounded just for this type
+when I do not use any other operations of the package. So the type is
+really misplaced.
+
+The proper place in light of all the arguments presented seems to be
+package Strings (RM A.4.1).
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Thursday, May 11, 2000 7:28 AM
+
+> The proper place in light of all the arguments presented seems to be
+> package Strings (RM A.4.1).
+
+Package Strings has pragma Pure, which disallows access types.
+
+Come to think of it, Standard has pragma Pure, too, which is *another*
+reason we can't put type String_Access in Standard.
+
+By the way, I wish there were a way to declare access types without
+allocators; then we could allow *those* kinds of access types in
+pragma-pure packages.
+
+I agree with you that String_Access is in a weird place.
+But it's harmless.  If you don't want to use it,
+you can easily declare your own.  Not ideal, but it works.
+
+*************************************************************
+
+From: Michael Yoder
+Sent: Thursday, May 11, 2000 10:11 AM
+
+Christopher Grein wrote:
+>
+>The proper place in light of all the arguments presented seems to be
+>package Strings (RM A.4.1).
+>
+Doing this would require (under current rules) changing package Strings
+from pure to preelaborated.  This potentially breaks existing code; it
+seems unlikely that a user would write an existing pure package that
+depends on Strings, but it's certainly imaginable (e.g., by renaming the
+exceptions).
+
+Earlier someone asked if anyone ever used the access type in
+Strings.Unbounded.  I have, two or three times.  In each case, I knew other
+parts of the program were using unbounded strings, so there was no cost to
+doing so.  I believe however that I would do it in any case, since IMO most
+large programs use unbounded strings at least once, and a small program
+won't be made a large one just by including one extra package.  Even so, I
+agree the type doesn't belong where it's put, and I have encountered at
+least one space-constrained program for which this consideration mattered.
+
+Perhaps a least bad solution would be to put the type in its own small
+child of Strings, and make the type in Strings.Unbounded be a "renaming as
+subtype" of that type.  This would (I think) be entirely compatible with
+the existing state of affairs.
+
+*************************************************************
+
+From: Christoph Grein
+Sent: Friday, May 12, 2000 12:01 AM
+
+> Doing this would require (under current rules) changing package Strings
+> from pure to preelaborated. ...
+
+OK, I again see the point.
+
+> Perhaps a least bad solution would be to put the type in its own small
+> child of Strings, and make the type in Strings.Unbounded be a "renaming as
+> subtype" of that type.  This would (I think) be entirely compatible with
+> the existing state of affairs.
+
+Hey, I think that's a brilliant idea.
+
+An access to String is so often needed that it should be predefined in the
+language, and Michael's proposal just does this in an innocuous way.
+
+    package Ada.Strings.Yoder is
+
+      pragma Preelaborate(Yoder);
+
+      type String_Access is access all String;
+
+      procedure Free (X : in out String_Access);
+
+    end Ada.Strings.Yoder;
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Friday, May 12, 2000 12:59 AM
+
+You can even imagine a special implementation of Ada.Strings;Yoder that
+would use some special storage pool to handle string accesses
+especially efficiently???
+
+*************************************************************
+
+From: Michael Yoder
+Sent: Friday, May 12, 2000 2:30 PM
+
+This is a good idea in any case (that is, it can be done for the type in
+Strings.Unbounded even if Strings.Yoder never becomes part of Ada0X :-).
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Thursday, May 11, 2000 8:21 PM
+
+> Bob, were you for or against type'Access the first time around?
+> I can't remember :-)
+
+Sometimes I can't remember what I was for or against in the past ;-),
+but in this case I've been for it, or something like it, all along.
+
+...
+> Ah Bob, if you supported it, then you can't move for a reconsideration.
+> To convince ourselves it is worth refighting this, we have to have at
+> least one person change their minds :-)
+
+OK.
+
+But it *was* brought up again, independently, as part of the solution to
+some other AI.  I can't remember which. (*Editor's note: This one!*)
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Friday, May 12, 2000 12:57 AM
+
+Well I sure would like to see something like typ'Access come back if it
+can be figured out how to do it cleanly.
+
+*************************************************************
+
+From: Christoph Grein
+Sent: Friday, May 12, 2000 12:14 AM
+
+
+> <<Where is T'Access defined? Oh - within record type definitions where it
+> stands for the current instance of the type.
+> >>
+>
+> Much more significantly, within tasks and protected objects to denote
+> the current concurrent object.
+>
+
+Thank you, Robert, for the details.
+
+Wouldn't it be a good idea to include T'Access with such a hint in Annex K?
+This annex is "informative", so IMO a good place for a statement like this.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Friday, May 12, 2000 1:05 AM
+
+<<Wouldn't it be a good idea to include T'Access with such a hint in Annex K?
+This annex is "informative", so IMO a good place for a statement like this.
+>>
+
+Well this already is in Annex K:
+
+4   X'Access
+                For a prefix X that denotes an aliased view of an object:
+
+THe case of subtype_name'Access is just a special case where subtype_name
+is defined to denote a specific aliased view, namely the current instance.
+It would be confusing to have an entry saying
+
+    T'Access    For a prefix that denotes a subtype T,
+
+... since in this case T does not denote a subtype.
+
+I suppose one could argue for a note, but my feeling is that notes belong
+in text books, not in the RM. Also notes in informative annexes are a bit
+odd I would think.
+
+Although this is a summary and is informative, it is definitely written
+in the style of normative text, so a note still needs to be labeled a
+note I would think.
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Friday, May 12, 2000 1:14 PM
+
+> I suppose one could argue for a note, but my feeling is that notes belong
+> in text books, not in the RM. Also notes in informative annexes are a bit
+> odd I would think.
+
+I guess they would be doubly informative.  ;-)
+
+> Although this is a summary and is informative, it is definitely written
+> in the style of normative text, ...
+
+In fact, this text is identical to the normative text in the body of the
+RM that describes these attributes.  So it's not surprising that it's in
+the same style.  ;-)
+
+In the source code for the RM (in Scribe), the attributes are written as
+macro calls, which generate the inline text, and also send the same text
+to a separate file, which gets sorted by attribute name, and then
+re-included back into Annex K.
+
+The pragmas have a similar mechanism.
+
+I think to build the Postscript version of the RM, you had to run Scribe
+three times in a row, because the output of one run would get sucked up
+into the next run as input, and it had to "settle down".  Sort of like
+bootstrapping a compiler.
+
+Randy is in the process of modernizing this software.  ;-)
+
+>... so a note still needs to be labeled a
+> note I would think.
+
+I tend to think it's not the job of ARG to teach people Ada.  As Robert
+says, there are textbooks.
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Friday, May 12, 2000 4:04 PM
+
+Mike and Robert,
+
+> Robert Dewar wrote:
+> >You can even imagine a special implementation of Ada.Strings;Yoder that
+> >would use some special storage pool to handle string accesses
+> >especially efficiently???
+>
+> This is a good idea in any case (that is, it can be done for the type in
+> Strings.Unbounded even if Strings.Yoder never becomes part of Ada0X :-).
+
+I guess you're going to be famous, Mike.  Nobody else has a predefined
+Ada package named after them.  Hey, maybe the ARG could make money by
+letting large corporations put their names on things.  Package Calendar
+could be renamed package FleetBank, and so on.
+
+Anyway, I'm not sure what you guys are getting at with efficient storage
+pools.  What's special about String_Access?  The fact that the
+designated type is an unconstrained array?  Surely not the fact that
+it's predefined.  What sort of special pool are you talking about, and
+whatever it is, why wouldn't it be a good idea for *any* "type Mumble is
+access all Unconstrained_Array;" that appears anywhere in any program?
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Friday, May 12, 2000 4:38 PM
+
+I wrote:
+
+> I guess you're going to be famous, Mike.  Nobody else has a predefined
+> Ada package named after them.
+
+Except for Ada herself, of course!
+
+*************************************************************
+
+From: Michael Yoder
+Sent: Monday, May 15, 2000 9:25 AM
+
+Bob Duff wrote:
+>Anyway, I'm not sure what you guys are getting at with efficient storage
+>pools.  What's special about String_Access?  The fact that the
+>designated type is an unconstrained array?  Surely not the fact that
+>it's predefined.  What sort of special pool are you talking about, and
+>whatever it is, why wouldn't it be a good idea for *any* "type Mumble is
+>access all Unconstrained_Array;" that appears anywhere in any program?
+
+String_Access is special because you can probably improve performance by
+making assumptions about the frequency of allocation of various lengths.  A
+simpler possibility is to choose the algorithm so as to specifically
+support Strings.Unbounded : this can be done by usiing a binary-buddy
+allocator when the length is a power of 2, for example.  (I haven't
+actually tried any such scheme, so I suppose I should qualify my enthusiasm
+by saying that the idea is potentially good rather than good.  But the idea
+of exploring such schemes is good.  :-)
+
+If Ada had a predefined generic for vectors of variable length, it could
+probably use the same allocator as that for Strings.Unbounded.
+
+If the above is still overly concise, I'm willing to elaborate further.
+
+*************************************************************
+
+From: Michael Yoder
+Sent: Monday, May 15, 2000 11:36 AM
+
+Robert Duff wrote:
+>I guess you're going to be famous, Mike.  Nobody else has a predefined
+>Ada package named after them.  Hey, maybe the ARG could make money by
+>letting large corporations put their names on things.  Package Calendar
+>could be renamed package FleetBank, and so on.
+
+I would hate to have to buy dark glasses in order to travel incognito.  :-)
+ So, let me propose Ada.Strings.Accesses as a name for this supposed package.
+
+>Anyway, I'm not sure what you guys are getting at with efficient storage
+>pools.
+
+I should perhaps state that my experience makes me at least as inclined to
+worry about fragmentation behavior as efficiency.  In either case, there is
+potential benefit in treating strings specially.
+
+*************************************************************
+
+
+
+