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: Robert A Duff <bobduff@world.std.com>
Subject: Re: "recursive" accept statement ??
Date: 1998/12/23
Message-ID: <wccempqzwjo.fsf@world.std.com>#1/1
X-Deja-AN: 425202158
Sender: bobduff@world.std.com (Robert A Duff)
References: <1998Dec15.122957@lri.fr>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1998-12-23T00:00:00+00:00
List-Id: <comp.lang.ada>

fv@lri.fr (Frederic Voisin) writes:

> 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) ????

The above "Put" refers to the entry, not to the procedure in Text_IO.
So it deadlocks.  The entry hides the other declaration of Put.

> When compiled with GNAT (gnat-3.10p on a Solaris machine) I get only the first
> 'Hello World" but not the second ...

And then it deadlocked, right?

> If allowed, what is the rationale behind, since such construct is much
> error-proned
> (and I had a hard time finding it)

Yes, I agree that hiding is error-prone.  I would prefer a rule that
made the above ambiguous (and therefore illegal).

The issue isn't accept statements, in particular.  You could have a
similar example with only procedures involved, and one procedure might
hide the one you *meant* to call.

Or something similar could happen with variable declarations,
or anything else.

Hiding causes something very similar to the "Beaujolais effect".
It is possible to insert a declaration into a working program, and have
it change its meaning, but still be legal.  That's a bad thing.
Hiding is really a "preference rule" -- inner things are preferred over
outer things and use-visible things.  And preference rules often cause
Beaujolais effects -- or in this case, something analogous.

> Shouldn't it deserve a warning ?? or a complain about ambiguity ?

The problem with warnings is that they're not standard.  It's not clear
(to the compiler writer, nor to the programmer) exactly which cases
should be warned about.

It *can* make sense to mention the name of an entry without the
task-name-dot prefix, at least in some unusual cases:

    task trace is
         entry put(str : string) ;
    end trace ;
    
    task body trace is

       task Nested;
       task body Nested is
       begin
	  Put("Hello, world."); -- No deadlock here.
       end Nested;

    begin
       accept Put (str : string) do
          declare
	     Y: String := Put.Str; -- No deadlock here.
	  begin
	     ...
          end;
       end Put:
    end Trace;

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.