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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,8f513ebf6208d431
X-Google-Attributes: gid103376,public
From: "David C. Hoos" <david.c.hoos.sr@ada95.com>
Subject: Re: "recursive" accept statement ??
Date: 1998/12/15
Message-ID: <755mja$mkp@hobbes.crc.com>#1/1
X-Deja-AN: 422489064
References: <1998Dec15.122957@lri.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Organization: Coleman Research Corporation
Newsgroups: comp.lang.ada
Date: 1998-12-15T00:00:00+00:00
List-Id: <comp.lang.ada>


Frederic Voisin wrote in message <1998Dec15.122957@lri.fr>...
>I have trouble understanding the behavior of the following program (or
>the rationale
>for allowing its behavior, if correct):
The problem is that Trace.Put hides Ada.Text_IO.Put, so you need to use the
fully-qualified subprogram name.  This is also why many Ada coding standards
forbid the use of "use" clauses except to make infix operators visible.
>-------------------------------------
>with Ada.text_io ; use Ada.text_io ;
>
>procedure Biz is
>
>task trace is
>     entry put(str : string) ;
>end trace ;
>
>task body trace is
>begin
>   accept Put (str : string) do
>          Ada.text_io.put(str);         -- works fine
>          Put(Str);                     -- behave like trace.Put(str) ????
>          New_Line;
>          end Put;
>end trace ;
>
>begin Trace.Put("Hello World");
>end Biz;
>---------------------------------------
>
>When compiled with GNAT (gnat-3.10p on a Solaris machine) I get only the
first
>'Hello World" but not the second, while I would have expected the
>Put(str) within
>the "accept" statement to correspond to Ada.text_io.put and not to an
>implicit
>rendez-vous with the same task - as if I had written trace.put(str) -
>that is sure
>to deadlock !!
>
>Is that the right behavior (omitting the name of the called task,
>especially from
>within itself !) or is it a bug (I cannot test it with another compiler)
>?
>If allowed, what is the rationale behind, since such construct is much
>error-proned
>(and I had a hard time finding it)
>Shouldn't it deserve a warning ?? or a complain about ambiguity ?
>I did not find something really illuminating in the Reference Manual or
>Rationale...
>
>Thanks