CVS difference for ais/ai-00304.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00304.txt

--- ais/ai-00304.txt	2003/10/29 22:54:12	1.3
+++ ais/ai-00304.txt	2004/02/21 04:15:10	1.4
@@ -477,5 +477,440 @@
 
 ****************************************************************
 
+From: Robert I. Eachus
+Sent: Friday, February 13, 2004  6:30 PM
+
+I thought there was an Ammendment AI fixing the problems with aliased
+(and 'Access and 'Unchecked_Access).  I just looked through the Ada
+Issues database and didn't find one.  Did it get filed under a name
+without aliased in the title, or is my memory playing tricks on me?
+(And if so, should I send this to Ada Comment?)
+
+To elaborate on the problem.  It makes no sense for an object of a type
+with aliased components to be other than aliased.  But currently that is
+not the case.  It either results in having to write aliased all over the
+place, or the kludge of using an access to the first component of the
+array or record when you really mean the object as a whole.  (And yes,
+there may be cases where the two are not the same, which is what makes
+it a kludge.)
+
+I would rather allow types (and subtypes) to be declared as aliased.
+That requires a syntax change, but it is certainly much clearer.  Just
+stating that objects with aliased components are implicitly aliased
+fixes the painful part.  (And as far as I  can tell, should just be a
+change in the semantics part.  I can't imagine any compiler currently
+creates unaliasable records or arrays with aliased components. ;-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February 13, 2004  8:04 PM
+
+I made some suggestions about allowing the word "aliased"
+pretty much anywhere the word "tagged" is allowed.
+I think it is a good idea for various reasons.
+Bob and I used to say that "tagged types work right"
+(e.g. predefined equality doesn't reemerge in generics,
+formal derived tagged types get the "right" primitives,
+etc.).  With this change, we could say "aliased" types
+work right.  They would sort of be like tagged records
+without the tag.  The actual wording changes in the
+manual didn't seem that bad.  Essentially some of
+the rules that currently say "tagged" would say aliased.
+And of course any tagged type is implicitly also
+an aliased type.  Presumably all task and protected
+types would be aliased as well.
+
+But alas, I never took it far enough to produce an AI.
+Maybe if someone prods me, I will find the time.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February 13, 2004  8:57 PM
+
+I was wrong -- it did make it into an AI:
+AI-304, "reemergence of "=" in generics"
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Friday, February 13, 2004  9:48 PM
+
+Thanks, I thought I remembered reading it.  Now let me make a few
+suggestions....
+
+First, the name of the AI should be changed to Aliased types and
+reemergence of "=", or the other way around. ;-)
+
+Second, I think that a lot of noise arose due to something that was (I
+hope) not a serious suggestion. I think for this proposal to be
+accepted, it must be totally upward compatible.  Which means that any
+new rules have to apply to the new types only.  To be honest: Tucker's
+proposal is to make aliased types like tagged types in generics.  I
+actually think that this is not just a good idea, I think it is the only
+way to meet the upward compatibility goal. I can imagine cases where the
+compiler can't tell that an aliased type has a full declaration that is
+tagged. (We could disallow that.)  But more important is the generic
+formal matching issue.
+
+For most compilers treating the (semantically) new category of types as
+tagged types with no visible primitive operations, or "=" as the only
+such operation, should be relatively painless.  But as I see it the big
+fix would be to fix the current problem of records and arrays with
+aliased components not being aliased.  I would prefer that the "fix" be
+that such types are implicitly aliased, but putting aliased in the type
+declaration would be no big deal.
+
+I also think that in that case (explicit declaration required for types
+with aliased components to also be aliased) it is worth allowing the
+aliased keyword in subtype declarations.  But there is no free lunch.
+If you have aliased subtypes, you have the possibility of calling a
+subprogram that has a parameter declared to be of an aliased subtype
+with a value of the type but not the subtype.  Dectecting the problem
+and rasing an exception is one solution.  But it seems a shame to create
+the same snake pit all over again in a much smaller area.   Better I
+think is to use Randy's approach.  Say that subtype conversion to an
+aliased subtype may cause copying and leave it at that.  (In other words
+it may result in a value in a register being put on the stack so it can
+be passed by reference.)  In any case, that will have to be done with
+explict type conversions.
+
+We require or dissallow aliased in derived type declarations depending
+on the parent view.  I don't think that simplifies anything since we
+currently allow derivation from private types where the full view is
+tagged.  This would just be another instance of the same.  And the
+thought of needing or not allowing aliased depending on the full type
+both raises upward compatibility issues and contract model violations.
+
+I think the way to go is that a formal of an aliased type can be matched
+only by any aliased type or any tagged type. An aliased type can match
+any private or limited private formal type. That way, if you want to use
+'Access in a generic on an object of a genric formal type, either the
+object or the formal type has to be explicitly aliased.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, February 14, 2004  3:29 PM
+
+> ...  I think for this proposal to be
+> accepted, it must be totally upward compatible.
+
+I believe it is upward compatible as written/
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Saturday, February 14, 2004  7:46 PM
+
+I agree.  But someone looking at the comments might think otherwise.  In
+one comment you (Tucker) said: "It might be time to address this issue
+directly, namely that "=" reemerges in generics, and doesn't compose. We
+have special rules for the "=" operator for tagged types, why not make
+this operator special for all types, requiring that if user-defined
+using the base subtype for scalar formals, or the first subtype for
+other types, then the predefined one does *not* reemerge in generics,
+and it composes properly.
+
+"Yes, I realize this would not be upward compatible, and would not be
+the same as other operators (but those don't *need* to compose), but
+remember that until Ada 95, it was very difficult to define your own
+equality operator anyway on a non-limited type."
+
+This is not part of the proposal as written, and it seems to have met
+with some pretty negative reaction. I think some people may have thought
+this was part of the proposal. Certainly the aliased types they can
+compose like tagged types, since right now the only aliased types are
+tagged types. If someone does want to put a proposal for composition of
+equality in untagged types that is
+upwardly compatible on the table fine. (I am happy with the current
+situation where "=" can be passed as a formal subprogram parameter with
+a default. It makes it a non-issue as far as I am concerned.)
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Saturday, February 14, 2004  9:13 AM
+
+I'm glad I brought it up then.  As I said in my previous post, I think
+that if we really want to get aliased (and 'Access) right, there has to
+be some way for a user to declare a TYPE to be aliased.  Subtype would
+be nice, but type is important.  The problem is that right now, if an
+abstraction author wants to use access types internally, he can either
+declare a type that has aliased components and write lots of wrapper
+suprograms, or make the user declare all objects as aliased, and all the
+operations on the type must have access parameters.  I personally think
+the latter is too ugly to use, and the former means that I have a "real"
+type which is passed by access, and a wrapper type which the user sees.
+
+But in the case of arrays, that gets painful too:
+
+  M,N: Integer := 10;
+
+  type Accessable_Matrix is array (Integer range 1..M, Integer range
+1..N) of Long_Float;
+
+  type Matrix is record
+    Actual: aliased Accessable_Matrix;
+  end record;
+
+  procedure Plus (L,R, Result: access Accessable_Matrix) is
+  begin
+    for I in L'Range(1) loop
+      for J in L'Range(2) loop
+        L(I,J) := R(I,J);
+      end loop;
+    end loop;
+  end Plus;
+
+  function "+" (L,R: Matrix) return Matrix is
+    L_Kludge: Matrix;
+    pragma Import(Ada,L_Kludge);
+    for L_Kludge'Address use L'Address;
+    R_Kludge: Matrix;
+    pragma Import(Ada,R_Kludge);
+    for R_Kludge'Address use R'Address;
+    Result: Matrix;
+  begin
+    Plus(L_Kludge.Actual'Access, R_Kludge.Actual'Access, Result.Actual'Access);
+    return Result;
+  end "+";
+
+I won't write a diatribe here about static matching rules and records
+with discriminants.  (There should be no problem with 'Access of a type
+with discriminants. Do we need a 'Unbounded_Access as well?)  Well, not
+a long diatribe anyway.  The example above useless as it is, compiles.
+(Of course, if it is inside a declarative part.)  I could make it more
+useful by putting it in a generic package with M and N as parameters,
+but I think this gives a bit of the flavor.  Any sensible programmer
+would have given up long ago, and passed 'Address instead.  Notice that
+to make this work, I have to take 'Address of Matrix objects anyway.
+(Maybe we should deprecate 'Address when used on objects which are not
+aliased.  But that is also another discussion, and certainly compilers
+can give a warning message.  But such a warning will only be useful, if
+we fix the aliased type issue.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, February 14, 2004  7:13 PM
+
+> I'm glad I brought it up then.  As I said in my previous post, I think
+> that if we really want to get aliased (and 'Access) right, there has to
+> be some way for a user to declare a TYPE to be aliased.  Subtype would
+> be nice, but type is important.  The problem is that right now, if an
+> abstraction author wants to use access types internally, he can either
+> declare a type that has aliased components and write lots of wrapper
+> suprograms, or make the user declare all objects as aliased, and all the
+> operations on the type must have access parameters.
+
+Or declare the type as tagged. Since all real abstractions should be
+controlled anyway, this is not a hardship. So I don't see a problem here.
+(This is precisely how Claw works, and there is no difficultly using access
+types internally, and it does not make the user do anything special.) But I
+don't expect general agreement on this point.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Saturday, February 14, 2004  8:06 PM
+
+Well, you certainly won't get it here.  I probably should have included
+the other example, which is right now compiling and passing test
+programs.  But the code is bulky and still in a state of flux.  It
+allows me to pass around a  view of a matrix which is a subset of a
+larger matrix.  (Which is why I need the aliasing.)  Maybe at some point
+I will extend it to the point of doing reference counting on the actual
+matrix objects, but right now that looks like a bad direction to head.
+For a large matrix I could have thousands of views in the normal course
+of events.  (Applying Strassen's algorithm to matrix multiplication.)
+True, the smallest view on average will be a 16x16 or so submatrix, but
+there will be a lot of them.  Much easier just to use nesting to insure
+that the views don't outlast the parent.
+
+The problem with the "real" version is that the user of the package has
+to declare any matrices to be passed in as aliased.  It seems much more
+"Ada like" to just declare the type as aliased.  But the point you keep
+missing, is that Matrices are ARRAY types, and there is no such thing in
+Ada as a tagged array type.  I can have arrays in record types, but that
+gets into the problems I demonstrated.  The arrays need to depend on
+discriminants, and with array objects it is hard enough to get static
+subtype matching.  With discriminated records it is messier.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Sunday, February 15, 2004  11:59 AM
+
+> Or declare the type as tagged. Since all real abstractions should be
+> controlled anyway, this is not a hardship. So I don't see a problem here.
+> (This is precisely how Claw works, and there is no difficultly using access
+> types internally, and it does not make the user do anything special.) But I
+> don't expect general agreement on this point.
+
+No, you won't.  ;-)
+
+I have lots of types that uses untagged and uncontrolled types,
+and I like it that way.  I'm annoyed when I have to say "tagged"
+just to get aliasedness.  We can agree to disagree on this point,
+but I don't think we should perturb the language design based
+on one person's viewpoint as to how the language should be used.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, February 16, 2004  7:53 AM
+
+My own view is that aliasedness is inherently evil, and personally
+I find it annoying that saying "tagged" automatically gets me
+this unwelcome feature.
+
+I agree that if this nasty feature is present, it should be
+orthogonal to taggedness as much as possible.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Monday, February 16, 2004  1:56 PM
+
+In principle, I agree.  However, the Yogi Berra quote you mentioned
+recently is relevant.  ;-)
+
+[Editor's note: The quote was in a different thread; here it is:
+"In theory there is no difference between theory and practice. In practice
+there is."]
+
+One problem is that functions can't have 'in out' parameters.
+(We all know what *you* think of that -- functions can have side
+effects, so long as you don't document them in the mode!)
+
+One workaround is to use a procedure instead.  But then you
+can't initialize objects at their declaration point, which is
+harmful.  Also, if the function result is, say, String, you
+can't use an 'out' parameter instead.  Think of something like
+"function Get_Line(F: in out Input_Stream) return String".
+
+Another workaround is to use access parameters.  But then you have to
+scatter "aliased" and '[Unchecked_]Access all over the place, for things
+that aren't "really" aliased -- you just want to pass things as
+parameters.  This kind of "crying wolf" is also damaging.
+
+The 'Unchecked_Access cases are particularly annoying, since "Unchecked"
+is supposed to mean, "Beware!  There might be dangling pointers lurking
+here", but all we're doing is passing a parameters.  If you write the
+code properly, dangling pointers are impossible in these cases, but the
+compiler can't help you make sure that's true.
+
+Marking the *type* as aliased would somewhat alleviate these problems.
+
+----------------
+
+Another problem is that there's no syntax for declaring parameters
+aliased.  You can't say:
+
+    procedure P(X: aliased in out T) is
+        Y: constant String := F(X'Unchecked_Access);
+
+Instead, you have to make T tagged, whether it needs a tag or not.
+I've had cases where this doubled the size of type T, and there
+were lots of T objects at run time.
+
+> I agree that if this nasty feature is present, it should be
+> orthogonal to taggedness as much as possible.
+
+Agreed.
+
+The history is interesting: The MRT originally proposed that "aliased"
+should be allowed for parameters.  The DR's and/or WG9 complained that
+this was unnecessary complexity, so the MRT took that syntax out.
+[IMHO, that kind of nonorthogonality *increases* complexity, but many
+reviewers seemed to measure complexity by the amount of new syntax.]
+A year or so later, the MRT discovered that aliased parameters are
+really necessary in some cases, particularly for tagged types.  We
+needed *some* way to get aliased parameters, so we decided that "tagged"
+implies "aliased" for parameters.  No new syntax, so nobody complained.
+
+IMHO, ``"tagged" implies "aliased" for parameters'' is not a
+simplification, compared to "aliased implies aliased; say what you
+mean".
+
+P.S. It's interesting to hear "aliasedness is inherently evil" from the
+inventor of the 'Unrestricted_Access attribute.  ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 16, 2004 11:13 PM
+
+> I have lots of types that uses untagged and uncontrolled types,
+> and I like it that way.  I'm annoyed when I have to say "tagged"
+> just to get aliasedness.  We can agree to disagree on this point,
+> but I don't think we should perturb the language design based
+> on one person's viewpoint as to how the language should be used.
+
+I don't quite see how saying that the status quo is good enough is going to
+"perturb the language design". I'm certainly not advocating any change here!
+
+I don't have any objection to this idea, it just doesn't seem that useful to
+me, and I'm afraid of spending resources on it that could be used on
+something more important (finishing pragma Assert, for instance). But, I
+suspect that Tucker will ultimately decide what gets in the Amendment by
+what he does or does not work on.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Tuesday, February 17, 2004  8:41 AM
+
+You were arguing against a particular AI, based on your opinion that all
+abstractions should be controlled.  I was just saying I don't find that
+argument convincing (whether you're advocating changing the language,
+or *not* changing the language -- either one is "language design"),
+because that viewpoint about controlled types is far from universal.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, February 18, 2004  10:25 AM
+
+> One problem is that functions can't have 'in out' parameters.
+> (We all know what *you* think of that -- functions can have side
+> effects, so long as you don't document them in the mode!)
+
+I see .. so a lot of this crud is coming from wilful failure
+to fix this obvious deficiency ... sort of like trying to
+cater the the folks who want to do unchecked conversions but
+don't allow the use of Unchecked_Conversion :-)
+
+> P.S. It's interesting to hear "aliasedness is inherently evil" from the
+> inventor of the 'Unrestricted_Access attribute.  ;-)
+
+I am not sure that I would elevate to "invention" this minor
+short hand for the use of 'Address and unchecked conversion!
+
+P.P.S. A common use of 'Unrestricted_Access is precisely to get around
+the nonsense restriction on IN/OUT parameters for functions. Though now
+that I think about it, quite a few of those uses could be replaced more
+cleanly by the use of pragma Import_Valued_Procedure -- DEC's neat work
+around for the restriction on function IN OUT parameters.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 18, 2004  3:31 PM
+
+> I see .. so a lot of this crud is coming from wilful failure
+> to fix this obvious deficiency ... sort of like trying to
+> cater the the folks who want to do unchecked conversions but
+> don't allow the use of Unchecked_Conversion :-)
+
+Well, I tried to fix that the 'right' way (see AI-323), and we actually
+discussed that at an ARG meeting - but, as we've said for many other Ada
+95-discussed issues, nothing has changed, and there is insufficient will to
+make the needed change.
+
+****************************************************************
+
 
 

Questions? Ask the ACAA Technical Agent