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: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: "recursive" accept statement ?? Date: 1998/12/15 Message-ID: #1/1 X-Deja-AN: 422605774 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <1998Dec15.122957@lri.fr> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1998-12-15T00:00:00+00:00 List-Id: 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)