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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,dbbbb21ed7f581b X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!newsfeed-fusi2.netcologne.de!news.netcologne.de!newsfeed-hp2.netcologne.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Operation can be dispatching in only one type Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <025105f2-5571-400e-a66f-ef1c3dc9ef32@g27g2000yqn.googlegroups.com> <1w0q3zxzw79pt$.5z0juiky7kfd$.dlg@40tude.net> <0f177771-381e-493b-92bb-28419dfbe4e6@k19g2000yqc.googlegroups.com> <1nbcfi99y0fkg.1h5ox2lj73okx$.dlg@40tude.net> <59acf311-3a4a-4eda-95a3-22272842305e@m16g2000yqc.googlegroups.com> <4b150869$0$6732$9b4e6d93@newsspool2.arcor-online.net> <18vlg095bomhd.8bp1o9yysctg$.dlg@40tude.net> <4b152ffe$0$7615$9b4e6d93@newsspool1.arcor-online.net> <19nhib6rmun1x$.13vgcbhlh0og9$.dlg@40tude.net> <4b1557d0$0$7623$9b4e6d93@newsspool1.arcor-online.net> <4b15bf2b$0$7623$9b4e6d93@newsspool1.arcor-online.net> Date: Wed, 2 Dec 2009 10:07:52 +0100 Message-ID: <1jcbtmi5rztyp$.norvlhez9i9$.dlg@40tude.net> NNTP-Posting-Date: 02 Dec 2009 10:07:52 CET NNTP-Posting-Host: 4ad45e6d.newsspool2.arcor-online.net X-Trace: DXC=Yi[FKgfXEX?^8FBo0_81f>A9EHlD;3Yc24Fo<]lROoR18kF7enW;^6ZC`4IXm65S@:3>?k_j=:EC@H12 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:8280 Date: 2009-12-02T10:07:52+01:00 List-Id: On Wed, 02 Dec 2009 02:13:14 +0100, Georg Bauhaus wrote: > On 12/1/09 7:47 PM, Dmitry A. Kazakov wrote: > >> It cannot be declared of Car, if it is not. > > Which brings us (or me, at least) to the problem of whether or > not the meaning of an Ada program (or a sequential subprogram) > will change if object X really "is" after "begin" or whether > its physical existence is allowed start just before actual > use. :-) X might show its existence through side effects > of its default initialization. > Rather implicit if the effect is important. Ada rules are rather complex, the object exists right after its declaration, but its existence is somewhat sleepy, a larva, not yet the butterfly: Consider the following: task type A is entry Hey; end A; type T (Greeting : access A) is new Ada.Finalization.Limited_Controlled with null record; overriding procedure Initialize (X : in out T); task body A is begin accept Hey; end A; procedure Initialize (X : in out T) is begin X.Greeting.Hey; end Initialize; With the above: declare X : aliased A; Y : T (X'Access); -- This is a deadlock! begin The object X (a task) is not completely initialized when Y's Initialize is called. This is one of nasty problems with tasks as objects. And in general I think that many feel uncomfortable with Ada declarations being executable. I have no clear idea how to approach this problem, though. >>> There is no way to perform an operation involving X in >>> its own declaration. >> >> But it can be used right after the declaration. > > Sure, but it isn't used, and the compiler will make sure > it isn't unless it has a value. That erodes the concept of scope, which idea is that the object is usable anywhere within its scope. >> Ada does not specify what happens with out parameters updated before an >> exception gets raised in the body of Foo: >> >> procedure Foo (X : out Car) is >> begin >> if HALT (p) then >> raise Baz; -- Is this legal? >> else >> X := Merzedes; >> end if; >> end Foo; > > If we were to integrate exceptions into normal control > flow like Java does? Contracted exceptions is a way to move the check down the code. Consider an invalid initial value, which is legal. Its validness is rather determined by outcome of some operations, e.g. reading it causes Constraint_Error. Then, with exception contracts, if you declared the program as not raising Constraint_Error, then the program with an invalid initial value could become illegal if Constraint_Error is not caught: declare raise no Constraint_Error; -- Imaginary syntax X : Car; begin Print (X.Tire); end; -- Illegal, this block might rise Constraint_Error declare raise no Constraint_Error; X : Valid_Car; -- Illegal require initialization by a valid value begin Print (X.Tire); end; -- Legal now, but fails at the declaration point declare raise no Constraint_Error; X : Valid_Car := My_Car; -- A valid value begin Print (X.Tire); end; -- No Constraint_Error >> Of course there is something to catch. The compiler has to do this. So the >> question is at which cost, how many false positives and negatives it will >> find? How scalable is this feature for more elaborated types? > > From the Java point of view, there are no false positives > or negatives. Of course there are, because it is a halting problem. So you need some optimistic or pessimistic estimation of: if False then Print (X.Tire); -- Is this illegal? If yes, that is a false positive end if; [Also see Randy's points] >> My example illustrated a situation where an >> uninitialized value might be an advantage, because one possible outcome of >> Foo is exception propagation, in which case leaving Result raw could save >> some vital nanoseconds of execution time. I don't buy this. > > Whether the out mode variable had been initialized in the > body or not, the exceptional situation might have destroyed > the value of the out mode parameter. A variable would not > be considered initialized, I'd think, in an exception handler, > unless the programmer says so (or assigns a value). No the problem is whether to treat a call to the body as legal. The problem is that you could not rely on its contract (out Car), in order to be able to decide whether this call would "initialize" the object. BTW, you consider ":=" as an initialization, but why? Where is a guaranty that it initializes the object by a "valid" value? I feel that very concept is somewhat inconsistent with ADT. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de