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=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.224.42.141 with SMTP id s13mr16573766qae.3.1370355485380;
        Tue, 04 Jun 2013 07:18:05 -0700 (PDT)
X-Received: by 10.182.55.71 with SMTP id q7mr95423obp.0.1370355485219; Tue, 04
 Jun 2013 07:18:05 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!eu.feeder.erje.net!feeder.erje.net!us.feeder.erje.net!news.glorb.com!p1no1365340qaj.0!news-out.google.com!y6ni74qax.0!nntp.google.com!ch1no792098qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Tue, 4 Jun 2013 07:18:04 -0700 (PDT)
In-Reply-To: <b15f6kFrfs6U1@mid.individual.net>
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: <55016aa4-4d69-4fd9-a2c9-a7eb7d3b00c5@googlegroups.com>
 <b15f6kFrfs6U1@mid.individual.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <81fc9059-d18b-49ad-8375-d436587f19bf@googlegroups.com>
Subject: Re: Possible for Ada 2020: "Cursors" for Arrays
From: Shark8 <onewingedshark@gmail.com>
Injection-Date: Tue, 04 Jun 2013 14:18:05 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:15695
Date: 2013-06-04T07:18:04-07:00
List-Id: <comp.lang.ada>

On Tuesday, June 4, 2013 12:19:00 AM UTC-6, Niklas Holsti wrote:
>=20
> I think it would be better to build this ability from syntax similar to
> the quantified expressions - "for all/some I in <range> =3D> ...". To
> avoid ambiguities when the array elements are Boolean we should use a
> new keyword instead of "all" or "some".

Why would it matter syntax-wise? (that is, I don't see how there would be a=
 problem when the elements are a boolean-type for the attribute form... tha=
t seems to only arise in a situation like you are proposing, jumping off "f=
or all"/"for some" syntactic constructs.)