From: stt@houdini.camb.inmet.com (Tucker Taft)
Subject: Re: "recursive" accept statement ??
Date: 1998/12/15
Date: 1998-12-15T00:00:00+00:00 [thread overview]
Message-ID: <F40vuE.9rx.0.-s@inmet.camb.inmet.com> (raw)
In-Reply-To: 1998Dec15.122957@lri.fr
Frederic Voisin (fv@lri.fr) wrote:
: ...
: 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 ??
As others have pointed out, the inner "Put" hides the one from Text_IO.
It would seem friendly to provide a warning when a task calls one
of its own entries, because it is certain to deadlock.
I suspect various compiler implementors are right now adding
this to their list of possible future "friendly warnings."
Unfortunately, it is not always trivial to create warnings which
are interpreted as "friendly" by all the recipients,
but this one looks like a good candidate...
: ... or a complain about ambiguity ?
: I did not find something really illuminating in the Reference Manual or
: Rationale...
As pointed out by others, entries are treated like procedures from the
point of view of hiding, and this is just like a procedure hiding
an outer definition with the same parameter profile.
: Thanks
--
-Tucker Taft stt@averstar.com http://www.averstar.com/~stt/
Technical Director, Intermetrics, Inc. Burlington, MA USA
An AverStar Company (www.averstar.com)
next prev parent reply other threads:[~1998-12-15 0:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-12-15 0:00 "recursive" accept statement ?? Frederic Voisin
1998-12-15 0:00 ` David C. Hoos
1998-12-15 0:00 ` Tucker Taft [this message]
1998-12-15 0:00 ` dennison
1998-12-15 0:00 ` Matthew Heaney
1998-12-15 0:00 ` Marc A. Criley
1998-12-15 0:00 ` Matthew Heaney
1998-12-23 0:00 ` Robert A Duff
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox