From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,a78600718149068b,start X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!r31g2000prg.googlegroups.com!not-for-mail From: troll Newsgroups: comp.lang.ada Subject: tagged primitive operation and freezing Date: Fri, 12 Nov 2010 19:24:44 -0800 (PST) Organization: http://groups.google.com Message-ID: NNTP-Posting-Host: 192.91.172.42 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1289618685 28216 127.0.0.1 (13 Nov 2010 03:24:45 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 13 Nov 2010 03:24:45 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: r31g2000prg.googlegroups.com; posting-host=192.91.172.42; posting-account=oVfT5woAAABM-b9_p2pX0lyTMvmsmxo_ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Lockheed Martin TSS; .NET CLR 2.0.50727; MS-RTC LM 8; InfoPath.2; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:16430 Date: 2010-11-12T19:24:44-08:00 List-Id: The following code snippet does not compile under two compilers that we have tried. Working with one of the vendors, we were wondering at first whether or not it should compile as in whether the instantiation is a freezing occurrence per 13.14:(5) and therefore the tagged primitive operation should be illegal, per RM95 3.9.2:(13) and 13.14: (16) Our reasoning (with the vendor) now as to why we agree that it shouldn't compile is based on the following. We wanted to run this by this group for any contrarian opinions or underlying reasons why this does not and should not compile. >From a compiler implementation perspective, the instantiation (rather like a macro expansion) will precede the primitive operation itself, even though the two are really conceptually coincident declarations. Should the primitive operation be allowed, no matter what the contents of the instantiation? Suppose the instance elaboration happens to declare some objects, and dispatch some primitive operations of its own type? It would violate the intent of the above rules. Should this still be allowed? I hope not. and also then this would NOT apply to UNTAGGED TYPES because (???) 13.14:(16): "[The explicit declaration of a primitive subprogram of a tagged type shall occur before the type is frozen (see 3.9.2).]" 3.9.2:(13): "The explicit declaration of a primitive subprogram of a tagged type shall occur before the type is frozen (see 13.14). [For example, new dispatching operations cannot be added after objects or values of the type exist, nor after deriving a record extension from it, nor after a body.]" Notice that Annotated Ada RM95 3.9.2:(13.c) clarifies: "We considered applying this rule to all derived types, for uniformity. However, that would be upward incompatible, so we rejected the idea." That means untagged types can add more new primitive ops even after the type is frozen. Yes! It seems the belief is that there's no harm in it, although it would be confusing (counter-intuitive) if that primitive op was overridden because the old overridden (not new overriding) primitive op body would reemerge (ie, still be called), same as in Ada83. generic type Object_T is private; procedure blah ( Param : Object_T ); ------- with blah; package oops is type a is tagged null record; -- any tagged type -- must be a type extension to induce failure: type Flight_T is new a with null record; -- fail function b (Flight : in Flight_T) return String; procedure c is new blah (Object_T => Flight_T); end;