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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,22ab316b1096e177,start
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,CP1252
Path: 
 g2news2.google.com!postnews.google.com!f33g2000yqh.googlegroups.com!not-for-mail
From: Shark8 <onewingedshark@gmail.com>
Newsgroups: comp.lang.ada
Subject: Tasks, Entries, and Variables of a Class-wide type
Date: Sun, 31 Oct 2010 22:40:37 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: 
 <7e77bb8f-17b6-4d51-9946-ea825f726682@f33g2000yqh.googlegroups.com>
NNTP-Posting-Host: 174.28.254.71
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1288590037 5598 127.0.0.1 (1 Nov 2010 05:40:37
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Mon, 1 Nov 2010 05:40:37 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: f33g2000yqh.googlegroups.com; posting-host=174.28.254.71;
 posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12)
 Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0E),gzip(gfe)
Xref: g2news2.google.com comp.lang.ada:16058
Date: 2010-10-31T22:40:37-07:00
List-Id: <comp.lang.ada>

I have a problem with tasks and class-wide types, namely the
dissallowance of entries returning a value (as a function would)
combined with the requirement that a variable of a class-wide type be
initialized before use.

The problem came up when I was writing a PostScript interpreter and,
implementing the PostScript type-system as a hierarchy of tagged
types, I wanted to be able so separate the parser from the actual
implementation so that it would be possible to have a single parser
service several PostScript interpreters (the state-machine/execution-
context/whatever-you-want-to-call-it).

I=92d originally wanted to have something like this:

Task Type Parser_Task is
 Entry Parse( Input : in out String ) Return PostScript_Object=92Class;
End Parser;

but that isn=92t allowed, but hey, that=92s ok because we have out
parameters. We just rearrange it so that we get:

Task Type Parser_Task is
 Entry Parse( Input : in out String; Object : Out
PostScript_Object=92Class );
End Parser;

But this doesn=92t work because in the calling-code a class-wide
variable needs to be initialized. {and a tag error is raised if you
try to assign an object with a differing tag to the variable}; so:

Declare
    Parser : Parser_Task;
    Some_Object : PostScript_Object=92Class:=3D PostScript_Dummy_Object;
Begin
    Parser.Parse( =935=94,  Some_Object ); =96 Makes Some_Object into a
PS_Integer w/ value of 5.
End;

is invalid because the tags won=92t match. We now have the problem where
the class-wide type needs to know what particular object the parser
will return, and the parser needs that class-wide variable wherein to
store the type in the first place. {A programming Catch-22 or Chicken/
Egg problem}

I figured out how to work around this problem, however. Inside the
Parser_Task we can do something like the following:

Task body Parse_Task is
[...]
Accept Parse( Input : in out String; Object : Out
PostScript_Object=92Class ) do
   Declare
      Temp : PostScript_Object=92Class:=3D Parse_Function( Input );
     For Temp=92Address use Output=92Address;
   Begin
      Null;
   End;
End Parse;
[...]

So, now we=92re left with the possible ramifications of overriding the
placement of our output variable. The only one that is immediately
obvious to me is that of the possibility of the original dummy class-
variable being over-written by an object that is actually larger.
(I.e. a null-record dummy-object being over written by an object
containing some data like a date/time stamp or somesuch.)

We *can* compensate with making the Dummy_Object object as large as
the largest object that Parser.Parse might return. But I am wondering
if I am missing something here.

{I=92m assuming there are perfectly good reasons we can=92t have free-
range class-wide types; like that of knowing how much memory to set
aside for the arbitrary and unknown object. And I assume that the same
is true of Task entries being forbidden from returning values [how
much space would be needed for an =93Array (Positive Range <>) of
Integer=94 within the rendevous?]}