From jj@ddci.dk Fri Apr 7 07:03:48 1995 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA21481; Fri, 7 Apr 95 07:03:48 EDT Received: from dkuug.dk by inmet.camb.inmet.com (4.1/SMI-4.1) id AA21406; Fri, 7 Apr 95 07:03:30 EDT Received: from ddci.dk by dkuug.dk with UUCP id AA03853 (5.65c8/IDA-1.4.4j for ada9x-mrt@inmet.camb.inmet.com); Fri, 7 Apr 1995 13:03:20 +0200 Received: from sparc3.ddci.dk by ddci.dk (4.0/j1.1.2) id AA11007; Fri, 7 Apr 95 11:51:13 +0200 Received: by sparc3.ddci.dk (4.1/SMI-4.1) id AA18000; Fri, 7 Apr 95 11:52:15 +0200 Date: Fri, 7 Apr 95 11:52:15 +0200 From: jj@ddci.dk (Jesper Joergensen) Message-Id: <9504070952.AA18000@sparc3.ddci.dk> To: ada9x-mrt@inmet.camb.inmet.com Cc: jj@ddci.dk, jut@ddci.dk Subject: Re: overriding in body X-Charset: ASCII X-Char-Esc: 29 !topic overriding in body !reference AARM95-7.3.1(7p);6.0 !reference 95-5115.a Jesper Joergensen 95-04-05 !reference 95-5116.a Tucker Taft 95-04-06 <> !discussion > > This was the intent. It doesn't violate the second principle of 3.9.2(13b), > nor make 3.9.2(13e) false, [are you using an older version of the AARM?], No, sorry, I use 6.0 but I made the citation wrong, it was supposed to read "3.9.2(13d)". > Perhaps, but this "twist" is necessary to correctly implement > the semantics. The expected implementation was that at the point of > the derivation, all primitives that would eventually be inherited will > be identified by the compiler. Their implicit declarations might be > postponed, but the compiler needs to know what primitives "exist" and > will "eventually" be declared to make appropriate choices about > which "dispatching slot" to assign to each explicitly declared primitive > subprogram. > > The overriding doesn't really "happen" in the body. The implicit > declaration, wherever it occurs, is overridden by the explicit declaration > (which must be in the spec somewhere if the tagged type declaration is). Well, 8.3(9) defines overriding as a phenomenon between two *declarations*, not between subprograms that just exist but are not declared. Therefore, I will still claim that we can't talk about any overriding until both of the declarations have actually taken place. In fact, we implemented the registration of overriding in our visibility system: when a declaration is made visible (implicitly or explicitly) a test for overriding is performed and registrered. Now we need registration of an overriding outside the visibility system before both declarations have been met. But now on to the next question, the purpose of which is to show whether we have understood things correctly. Consider the slightly more complicated example: package Parent is type Root is tagged null record; private procedure Op2( X : Root ); -- private primitive for Root end Parent; package Parent.Child is package Nested is type T4 is new Root with null record; -- T4 inherits Op2, but Op2 isn't declared until the body private procedure Op2( X : T4 ); -- overrides, BUT NOT YET type T5 is new T4; -- inherits both Op2's, the one inherited -- from that in the previous line is -- implicitly declared here, the other one -- is implicitly declared in the body end Nested; private -- nothing interesting happens to Op2 here end Parent.Child; package body Parent.Child is package body Nested is -- Here a second inherited Op2 gets declared for T5 and because this one -- occurs later than the implicit declaration that occurred at the -- declaration of T5 itself, this one is overriding the previous one -- [8.3(12)] (no matter who overrides who for T4). procedure Op2( X : T4 ) is begin null; end Op2; end Nested; end Parent.Child; Isn't it surprising that the overriding subprogram of T5 is exactly the overridden one for T4, i.e we dispatch to the same Op2 for Root and T5, but for the intervening T4 we dispatch to the explicitly declared one. I would have assumed that because T4 decides to override Op2, this overriding would also count for its derivatives. If, in the body Nested we derive T6 from T5, which of the inherited Op2's win? > > -Tuck > /Jesper From ncohen@watson.ibm.com Fri Apr 7 10:30:04 1995 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA22419; Fri, 7 Apr 95 10:30:04 EDT Received: from watson.ibm.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA28605; Fri, 7 Apr 95 10:30:01 EDT Message-Id: <9504071430.AA28605@inmet.camb.inmet.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2021; Fri, 07 Apr 95 10:29:59 EDT Date: Fri, 7 Apr 95 10:29:59 EDT From: "Norman H. Cohen" To: ada9x-mrt@inmet.com Subject: Questions on Annex B !topic What are the rules for named notation in pragmas? !reference RM95-2.8(4) !reference RM95-B.1(5) !reference RM95-B.1(6) <> The syntax given for pragma Import is pragma Import ( [Convention => ] convention_identifier -- (1) , [Entity =>] local_name -- (2) [ , [External_Name => ] string_expression ] -- (3) [ , [Link_Name => ] string_expression ] ) ; -- (4) (and similarly for pragma Export). Is there a rule from which I can deduce that pragma Import (C, Raise_Signal, "raise"); means pragma Import (C, Raise_Signal, External_Name => "raise"); (by eliding the text in the outer brackets on line (4) and the text in the inner brackets on line (3)) rather than pragma Import (C, Raise_Signal, Link_Name => "raise"); (by eliding the text in the outer brackets on line (3) and the text in the inner brackets on line(4))? 2.8(4) says that one may not supply an argument name for one pragma argument and elide it for a later one, but this does not resolve the syntactic ambiguity. In fact, the rule in 2.8(4) would only be necessary if named pragma argument associations could be reordered in the same way as named parameter and generic parameter associations: pragma Import (C, Raise_Signal, Link_Name => "raise", External_Name => "._raise"); Is the intent to allow this pragma? It is inconsistent with the syntax in B.1(5). !topic Can wchar_t be signed? !reference RM95-B.3(31) !from Norman Cohen <> !discussion Paragraph 30 indicates that the definition of Interfaces.C.wchar_t is implementation defined. However, since wide_nul is meant to have a representation of zero, the initialization of wide_nul to wchar_t'First in paragraph 31 suggests that wchar_t can be an enumeration type or a modular type, but not a signed integer type. Is that the intent? !topic Mapping between Interfaces.C.char and Standard.Character !reference RM95-B.3(46) !from Norman Cohen <> !discussion This paragraph states that To_Ada and To_C map between Character and char, but does not explain how. Presumably, Interfaces.C.char corresponds to the C type char, i.e., to the native character set of the target machine. Type Character, of course, always corresponds to Latin-1, regardless of the target machine. On an EBCDIC machine, does To_C('A') yield the C.Interfaces.char value corresponding to EBCDIC 'A', or does it yield the character whose EBCDIC code is Character'Pos('A')? !topic Effect of Update(Null_Ptr,...) !reference RM95-B.3.1(44) !from Norman Cohen <> !discussion Does Update raise Dereference_Error if Item = Null_Ptr?