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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,344faf475a6f812a
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.224.215.194 with SMTP id hf2mr23197753qab.0.1366758020887;
        Tue, 23 Apr 2013 16:00:20 -0700 (PDT)
X-Received: by 10.50.180.197 with SMTP id dq5mr6236590igc.17.1366758020848;
 Tue, 23 Apr 2013 16:00:20 -0700 (PDT)
Path: 
 ef9ni12521qab.0!nntp.google.com!gp5no5413606qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Tue, 23 Apr 2013 16:00:20 -0700 (PDT)
In-Reply-To: <lya9opdwaz.fsf@pushface.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=69.20.190.126;
 posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
NNTP-Posting-Host: 69.20.190.126
References: <97967083-d21d-4de2-aeb8-76d0d5818993@googlegroups.com>
 <f91ac67c-02c9-43fd-982c-a58567aa9a1b@googlegroups.com>
 <lya9opdwaz.fsf@pushface.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b3c264c9-382e-40f6-a44a-6964f2c65a8d@googlegroups.com>
Subject: Re: Interresting difference in Normal-Returns/Expression-Functions
 and Extended-Returns.
From: Shark8 <onewingedshark@gmail.com>
Injection-Date: Tue, 23 Apr 2013 23:00:20 +0000
Content-Type: text/plain; charset=ISO-8859-1
Date: 2013-04-23T16:00:20-07:00
List-Id: <comp.lang.ada>

On Tuesday, April 23, 2013 10:52:04 AM UTC-6, Simon Wright wrote:
> 
> By the way, what's the significance of 'constant' in 'not null access
> constant Testing'?

It means you can't swap the task-access out w/ a new allocator -- Though you might not be able to do that anyway. -- I was going for the most constrained types/conditions possible while I was experimenting.

> 
> > The moral: Whether or not you think anonymous access types are evil,
> > anonymous access types to *tasks* definitely can have some surprising
> > consequences (because of the task termination and dependency rules),
> > and should be avoided.
> 

Yes; this was surprising. Though this brings up an interesting point: how would you be able to have an array of tasks that have a discriminant?