From ncohen@us.ibm.com Thu Feb 26 02:02:48 1998 Return-Path: Received: from inmet.com by dsd.camb.inmet.com (SMI-8.6/SMI-SVR4) id CAA18996; Thu, 26 Feb 1998 02:02:48 -0500 Received: from smtp3.ny.us.ibm.com by inmet.com (SMI-8.6/SMI-SVR4) id CAA01603; Thu, 26 Feb 1998 02:02:46 -0500 Received: from relay1.server.ibm.com (relay1.server.ibm.com [9.14.2.98]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id BAA66780 for ; Thu, 26 Feb 1998 01:58:14 -0500 Received: from US.IBM.COM (d01lms03.pok.ibm.com [9.117.30.8]) by relay1.server.ibm.com (8.8.7/8.8.7) with SMTP id CAA10328 for ; Thu, 26 Feb 1998 02:01:25 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU032 id 5010300015644693; Thu, 26 Feb 1998 02:01:13 -0500 From: Norman H Cohen To: Subject: Re: 98.0225 fulltext of ada-comments Message-ID: <5010300015644693000002L032*@MHS> Date: Thu, 26 Feb 1998 02:01:13 -0500 MIME-Version: 1.0 Content-Type: text/plain content-length: 639 !topic object subtype must statically match designated subtype !reference RM95-4.6 (16) !from Norman Cohen !reference 1998-15802.a Ted Baker 1998-2-25 <> !discussion I think the rule should stay as is, so that a compiler has the choice of letting access-to-unconstrained contain or point to dope, even while access-to-constrained does not. (The trick of putting the dope just BEFORE the address pointed to is not generally available in Ada 95 because a packed record, or one with a record-rep clause, could have aliased String(1 .. 10) components.) It's not all that terrible to have to write Buf: aliased String := (1 .. 10 => ' '); From Randy@rrsoftware.com Thu Feb 26 12:18:34 1998 Return-Path: Received: from inmet.com by dsd.camb.inmet.com (SMI-8.6/SMI-SVR4) id MAA20347; Thu, 26 Feb 1998 12:18:34 -0500 Received: from sw-eng.falls-church.va.us by inmet.com (SMI-8.6/SMI-SVR4) id MAA09730; Thu, 26 Feb 1998 12:18:33 -0500 Received: from janusada.msn.fullfeed.com by sw-eng.falls-church.va.us (8.8.8/) id RAA04293; Thu, 26 Feb 1998 17:14:45 GMT Received: from tallboy (192.4.87.2) by server.rrsoftware.com (EMWAC SMTPRS 0.80) with SMTP id ; Thu, 26 Feb 1998 11:21:52 -0600 Received: by tallboy with Microsoft Mail id <01BD42A8.66FDF420@tallboy>; Thu, 26 Feb 1998 11:19:28 -0600 Message-ID: <01BD42A8.66FDF420@tallboy> From: Randy Brukardt To: "ada-comment@sw-eng.falls-church.va.us" , "'Ted Baker'" Subject: RE: "statically matching subtypes" Date: Thu, 26 Feb 1998 11:19:27 -0600 Encoding: 109 TEXT content-length: 4017 !topic object subtype must statically match designated subtype !reference RM95-4.6 (16) !reference 1998-15802.a Ted Baker 1998-2-25 !from Randy Brukardt <> !discussion >What makes this even more absurd is that there is >no implementation reason for this restriction. This is completely wrong. There is a MAJOR implementation problem here. It is caused by the need for unconstrained arrays to have array descriptors. >After all, if the user had declared >buf : aliased string := "garbage initial value"; >Then "p (buf'access);" would be legal, and it is equivalent work for the implementation. Not really. When you declare "aliased string", the compiler will create an array as part of, or alongside the object. Taking 'access of the object then can include the necessary array descriptor. If you have instead buf : aliased string(1..10); most compilers will not generate any array descriptor. Then, when you take 'access, you would need to create a descriptor - but how can you get the lifetime right? You can't allocate the descriptor locally, because the access type probably will last longer than that. If you allocate it from the heap, you will never know when it is safe to deallocation it, so you will have a storage leak. We discovered this during the U/I work. I was prepared to make "aliased" change the representation of items, but I believe that the language design team decided that they didn't want "aliased" to change the representation of items, and therefore added the rule you are complaining about. >I strongly believe that this problem is serious enough to make a >corregendum to the ARM. The impact on implementations would be substantial, more memory would be consumed by programs, aliased arrays which were stored in disk files would not be readable with "corrected" compilers, and some previously legal representation clauses would have to be rejected. This is much too major of a change for the ARG to make. I recommend that the rule stand. >The fact that this is (apparently) illegal was not detected, >since earlier Ada compilers were not enforcing this rule. Janus/Ada has always enforced the rule (since it was put in after we discovered the implementation problem). The problem is that the ACVC had a couple of tests which insisted that the rule NOT be implemented. We of course disputed the tests, and they were eventually withdraw, but the net effect was that ACVC 2.0.1 encouraged the wrong implementation, and did nothing to check for the correct implementation. >We are now faces with the extremely embarassing need to >backtrack to the C-language equivalent: >with system; >procedure fooc is > procedure p (s : system.address; len : natural); > procedure p (s : system.address; len : natural) is > begin null; > end p; > buf : aliased string (1..10); >begin > p (buf'address, buf'length); >end fooc; Yes, we've run into this in Claw. But you don't have to all the way to System.Address. You still can get most of the type checking by making the declaration: procedure foo_better is type Access_Character is access all Character; type better_string is array (positive range <>) of aliased Character; procedure p (s : Access_Character; len : natural); procedure p (s : Access_Character; len : natural) is begin null; end p; buf : better_string (1..10); begin p (buf(1)'access, buf'length); end foo_better; I also find the whole notion of needing to pass a pointer at a string dubious. While C bindings such as Win32 is full of them, we have not found a single case yet in the construction of Claw where we had to make that visible to the user. In every case we've seen, you can use either "Item : in String" (if the item is only going to read), or "Item : in out String" if the item is going to written. I wonder if your POSIX people need to work harder to provide an appropriate Ada binding. I certainly don't want to change the language so a dubious coding practice can be supported. From stt@inmet.com Thu Feb 26 14:24:32 1998 Return-Path: Received: from inmet.com by dsd.camb.inmet.com (SMI-8.6/SMI-SVR4) id OAA20833; Thu, 26 Feb 1998 14:24:31 -0500 Received: from houdini.camb.inmet.com by inmet.com (SMI-8.6/SMI-SVR4) id OAA12774; Thu, 26 Feb 1998 14:24:22 -0500 Received: by houdini.camb.inmet.com (SMI-8.6/SMI-SVR4) id OAA10717; Thu, 26 Feb 1998 14:24:21 -0500 Date: Thu, 26 Feb 1998 14:24:21 -0500 From: stt@inmet.com (Tucker Taft) Message-Id: <199802261924.OAA10717@houdini.camb.inmet.com> To: todd.allen@mail.hcsc.com, ada9x-mrt@inmet.com Subject: Re: Generic formal subprograms as dispatching operations X-Newsreader: TIN [version 1.1 PL8] content-length: 3237 !topic Generic formal subprograms as dispatching operations !reference RM95-3.2.3(7) !reference RM95-12.5.1(21) !reference RM95-12.3(15-16) !reference RM95-8.3(10) !reference RM95-3.9.2(1,20) !reference RM95-8.5.4(12) !reference 1998-15801.a Todd Allen 98-02-19 !from Tucker taft 98-02-26 !keywords generic formal subprogram, primitive, dispatching <> !discussion : The definition of primitive subprograms in 3.2.3(7) suggests that the copies : of generic formal subprograms in an instance can be dispatching operations if : they override any implicitly declared primitive subprograms there. This paragraph was not intended to apply to formal subprograms; some wording improvement is in order. In any case, the rules for tagged types are constructed so that where a call on a dispatching subprogram goes is independent of the location of the call, and is determined entirely by which conceptual "slot" the specified dispatching operation occupies. The rules for calls on primitives of untagged types are not based on a run-time "slot" but rather on the normal compile-time visibility rules. [This is implied by 3.9.2(14,20). See also AARM 3.9.2(20.a-20.g).] The primitive subprograms of a formal type are specified in 12.5(8) and 12.5.1(21); formal subprograms are not primitive subprograms, even if they hide primitives of the formal type. : Brief Digression: : The text in RM95 3.2.3(7) and the text throughout RM95 3.9.2 refer to : types and subprograms as opposed to views of types and views of : subprograms. I have assumed that this was for purposes of brevity. Which primitives of a type are visible are determined by of the corresponding (implicit or explicit) subprogram declarations are visible. It does not depend on which "view" of the *type* is being used, though the two might be related because the implicit subprogram declarations generally happen at the same point as the type declaration (though not always!). : ... Many : of the issues discussed herein also exist for renaming declarations. : There is a note in RM95 8.5.4(12) which mentions that primitiveness is : determined by the location of the renaming-as-declaration, as for any : declaration of (a view of) a subprogram. This suggests that the "a view : of" text was intended throughout RM95 3.2.3 and RM95 3.9.2. Yes, that is probably true for the subprograms. It is not necessary to insert "a view of" when referring to types. : Because the "=" (3) and Foo (4) operations are primitive operations of (a : view of) a tagged type in each of the instances, they should also be : dispatching operations by RM95 3.9.2(1). Formal subprograms are not primitives. : ... : So, what subprograms should be executed for calls to the "=" (3) and Foo (4) : operations in each of the calls to Test? As mentioned above, the rules for calls on dispatching operations are such that compile-time view is irrelevant. All that matters is what address ends up in the "slot" at run-time, and that does not change based on compile-time view. : -- : Todd Allen : Concurrent Computer Corporation : Fort Lauderdale, FL 33309 -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA From todd@tawny.ssd.hcsc.com Thu Feb 26 15:25:56 1998 Return-Path: Received: from inmet.com by dsd.camb.inmet.com (SMI-8.6/SMI-SVR4) id PAA21131; Thu, 26 Feb 1998 15:25:56 -0500 Received: from hawk.hcsc.com by inmet.com (SMI-8.6/SMI-SVR4) id PAA14264; Thu, 26 Feb 1998 15:25:54 -0500 Received: from tawny.ssd.hcsc.com by hawk.hcsc.com (5.61/harris-5.1) id AA07308; Thu, 26 Feb 98 15:25:52 -0500 Received: by tawny.ssd.hcsc.com (5.61/CX/UX-7.1) id AA04433; Thu, 26 Feb 98 20:25:50 GMT From: todd@tawny.ssd.hcsc.com (Todd Allen) Message-Id: <9802262025.AA04433@tawny.ssd.hcsc.com> Subject: Re: Generic formal subprograms as dispatching operations To: stt@inmet.com (Tucker Taft) Date: Thu, 26 Feb 1998 15:25:50 -0500 (EST) Cc: ada9x-mrt@inmet.com, ada@tawny.ssd.hcsc.com In-Reply-To: <199802261924.OAA10717@houdini.camb.inmet.com> from "Tucker Taft" at Feb 26, 98 02:24:21 pm Reply-To: todd.allen@mail.hcsc.com X-Mailer: ELM [version 2.4 PL24] Content-Type: text content-length: 4159 !topic Generic formal subprograms as dispatching operations !reference RM95-3.2.3(7) !reference RM95-12.5.1(21) !reference RM95-12.3(15-16) !reference RM95-8.3(10) !reference RM95-3.9.2(1,20) !reference RM95-8.5.4(12) !reference 1998-15801.a Todd Allen 98-02-19 !from Todd Allen 98-02-26 !keywords generic formal subprogram, primitive, dispatching <> !discussion Tucker, Thank you for your quick response to this comment. > > This paragraph [3.2.3(7)] was not intended to apply to formal > subprograms; some wording improvement is in order. In any case, the > rules for tagged types are constructed so that where a call on a > dispatching subprogram goes is independent of the location of the > call, and is determined entirely by which conceptual "slot" the > specified dispatching operation occupies. The rules for calls on > primitives of untagged types are not based on a run-time "slot" but > rather on the normal compile-time visibility rules. [This is > implied by 3.9.2(14,20). See also AARM 3.9.2(20.a-20.g).] > This is the answer that I was expecting, and is in fact the interpretation that we've implemented. I agree that the wording needs a little work to explicitly exclude formal subprograms as primitives. > > The primitive subprograms of a formal type are specified in 12.5(8) > and 12.5.1(21); formal subprograms are not primitive subprograms, even > if they hide primitives of the formal type. > > Which primitives of a type are visible are determined by of the corresponding > (implicit or explicit) subprogram declarations are visible. > It does not depend on which "view" of the *type* is being used, though > the two might be related because the implicit subprogram declarations > generally happen at the same point as the type declaration (though > not always!). > > Yes, that is probably true for the subprograms. It is not necessary > to insert "a view of" when referring to types. > I agree that the primitives of formal types are well-defined. My reason for believing that the "a view of" text was necessary for types as well as subprograms turns out to be faulty. But I still have an issue on which I would appreciate some clarification, so I will explain. In the instance, the formal type declares a new view of the actual type, and the implicit subprograms of the formal type declare new views of the primitives of the actual type. Because the implicit subprograms are new views, I believe that primitiveness has to be determined for them independently via the rules in 3.2.3(2-7) rather than the on the basis of the subprograms of which they are views (rather like subprogram renaming declarations). Upon rereading 3.2.3(2-7), I notice that even if the "a view of" text was inserted for types into that section, the implicit subprograms in the instance would still not be considered primitive (because the view of the type would not be in a package_specification). So, how are the implicit subprograms in an instance considered primitive? Is it simply because they are copies of the primitives of the formal type? Is primitiveness an aspect that is copied from the implicit declarations in the generic to the implicit declarations of the instance? > > As mentioned above, the rules for calls on dispatching operations are such > that compile-time view is irrelevant. All that matters is what address > ends up in the "slot" at run-time, and that does not change based on > compile-time view. > Am I correct in assuming that even though the formal subprograms are not considered primitive operations, they still override the primitive operations for visibility purposes? This would mean that the formal subprograms would be called (in a non-dispatching manner) instead of their dispatching counterparts. So, in the example in my comment, for calls to Test in each of the instances of G, the calls to "=" and Foo would be non-dispatching calls to the actual subprograms associated with the formal subprograms. Is this correct? -- Todd Allen Concurrent Computer Corporation Fort Lauderdale, FL 33309 From stt@inmet.com Thu Feb 26 17:40:10 1998 Return-Path: Received: from inmet.com by dsd.camb.inmet.com (SMI-8.6/SMI-SVR4) id RAA21571; Thu, 26 Feb 1998 17:40:10 -0500 Received: from houdini.camb.inmet.com by inmet.com (SMI-8.6/SMI-SVR4) id RAA17450; Thu, 26 Feb 1998 17:40:06 -0500 Received: by houdini.camb.inmet.com (SMI-8.6/SMI-SVR4) id RAA22348; Thu, 26 Feb 1998 17:40:06 -0500 Date: Thu, 26 Feb 1998 17:40:06 -0500 From: stt@inmet.com (Tucker Taft) Message-Id: <199802262240.RAA22348@houdini.camb.inmet.com> To: stt@inmet.com, todd.allen@mail.hcsc.com Subject: Re: Generic formal subprograms as dispatching operations Cc: ada9x-mrt@inmet.com, ada@tawny.ssd.hcsc.com content-length: 3023 !topic Generic formal subprograms as dispatching operations !reference RM95-3.2.3(7) !reference RM95-12.5.1(21) !reference RM95-12.3(15-16) !reference RM95-8.3(10) !reference RM95-3.9.2(1,20) !reference RM95-8.5.4(12) !reference 1998-15801.a Todd Allen 98-02-19 !reference 1998-15806.a Tucker Taft 98-02-26 !reference 1998-15807.a Todd Allen 98-02-26 !keywords generic formal subprogram, primitive, dispatching <> !discussion > ... > In the instance, the formal type declares a new view of the actual type, > and the implicit subprograms of the formal type declare new views of the > primitives of the actual type. Because the implicit subprograms are new > views, I believe that primitiveness has to be determined for them > independently via the rules in 3.2.3(2-7) rather than the on the basis of > the subprograms of which they are views (rather like subprogram renaming > declarations). Upon rereading 3.2.3(2-7), I notice that even if the "a > view of" text was inserted for types into that section, the implicit > subprograms in the instance would still not be considered primitive > (because the view of the type would not be in a package_specification). > > So, how are the implicit subprograms in an instance considered primitive? > Is it simply because they are copies of the primitives of the formal type? > Is primitiveness an aspect that is copied from the implicit declarations > in the generic to the implicit declarations of the instance? Primitiveness is generally only important for calls on dispatching operations and when type derivation takes place. It is certainly the intent that calls on the implicitly declared primitives of the formal become calls on dispatching operations if the actual type is tagged. As far as type derivation, in the instance, deriving from a formal becomes equivalent to deriving from the actual, which means that in the instance, you might actually end up with more implicit declarations. This is explained in 12.3(16-17). > > As mentioned above, the rules for calls on dispatching operations are such > > that compile-time view is irrelevant. All that matters is what address > > ends up in the "slot" at run-time, and that does not change based on > > compile-time view. > > > > Am I correct in assuming that even though the formal subprograms are not > considered primitive operations, they still override the primitive > operations for visibility purposes? This would mean that the formal > subprograms would be called (in a non-dispatching manner) instead of their > dispatching counterparts. Yes. > So, in the example in my comment, for calls to Test in each of the > instances of G, the calls to "=" and Foo would be non-dispatching calls to > the actual subprograms associated with the formal subprograms. Is this > correct? I don't have your example in front of me, but that sounds right. > -- > Todd Allen > Concurrent Computer Corporation > Fort Lauderdale, FL 33309 -Tuck