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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!nike!ucbcad!ucbvax!ADA20.ISI.EDU!RRACINE
From: RRACINE@ADA20.ISI.EDU (Roger Racine)
Newsgroups: net.lang.ada
Subject: Task entries in generics
Message-ID: <8607021556.AA19953@ucbvax.Berkeley.EDU>
Date: Wed, 2-Jul-86 11:21:08 EDT
Article-I.D.: ucbvax.8607021556.AA19953
Posted: Wed Jul  2 11:21:08 1986
Date-Received: Thu, 3-Jul-86 06:59:58 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

Can anyone give a reason why entries are not allowed as parameters to
generics? The ability to use selective calls can sometimes be necessary
to avoid deadlocks, and making a task entry look like a procedure makes 
it impossible to use a selective call.

It would seem easy enough to add a "with entry ________" construct to
the formal part of the generic, following the same rules as for procedures.
Then any entry having the correct parameters could be used as the actual
parameter in an instance of the generic.

One reason suggested by the person who asked me about it is that the syntax
of an entry call always has the "TASK.ENTRY" form. Is there some problem
with compiler construction or readability that would make the procedure
syntax a problem? One could (if necessary) make the formal parameter
have the correct syntax ("with entry T.E"). 

There is, of course, a way around this problem. I would appreciate comments
as to whether the workaround is as distasteful to others as it is to me.
One can create a procedure which has the same parameters as the entry,
plus a parameter of type DURATION (mode "in") and an "out" parameter
of type BOOLEAN to specify whether the rendezvous occurred. This approach
works well when the entry has no "out" parameters, but forces the
procedure to put something in the parameters if they exist.

By the way, it was not possible to use an access to a task type,
because the tasks were being declared in a generic; therefore, each
instance created (necessarily for this application) a new type.
The entries needed for the generic I am trying to design were identical
(START_TASK, STOP_TASK, that kind of entry) in all instances.

If anyone has a more elegant solution, I would love to look at it.

Please send them to INFO-ADA@ADA20.ISI.EDU so that
       1) Others can see them.
       2) Others do not duplicate them.


Roger Racine
C.S. Draper Laboratory
RRACINE@ADA20.ISI.EDU
-------