From vsnyder@vanpc.jpl.nasa.gov  Tue Apr  4 00:23:42 2000
Received: from vanpc.jpl.nasa.gov (vanpc.jpl.nasa.gov [137.79.7.57])
	by dkuug.dk (8.9.2/8.9.2) with ESMTP id AAA43886
	for <SC22WG5@dkuug.dk>; Tue, 4 Apr 2000 00:23:41 +0200 (CEST)
	(envelope-from vsnyder@vanpc.jpl.nasa.gov)
Received: from vanpc.jpl.nasa.gov (localhost [127.0.0.1])
	by vanpc.jpl.nasa.gov (8.9.3/8.9.3) with ESMTP id PAA03259
	for <SC22WG5@dkuug.dk>; Mon, 3 Apr 2000 15:28:25 -0700
Message-Id: <200004032228.PAA03259@vanpc.jpl.nasa.gov>
X-Mailer: exmh version 2.0.3
To: SC22WG5@dkuug.dk
Subject: Interpretation 001
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 03 Apr 2000 15:28:25 -0700
From: Van Snyder <vsnyder@vanpc.jpl.nasa.gov>


One of the results of discussions concerning Interpretation 001 is that
some folks would prefer that implied DO's (all kinds) are scoping units,
that the induction variables of them are implicitly declared therein,
and follow the usual rules for host association.

Other folks point out that this would constitute more of a change than
an interpretation, and ought to be addressed as an extension, in F200x
or later.

An obvious (to me) compatible extension that wouldn't break existing
codes, no matter how Interpretation 001 comes out, is to allow a
"<type spec> ::" (with the type required to be INTEGER), as we do
for array constructors and ALLOCATE statements, in implied DO's.  The
effect is to create a clearly new induction variable, with specifiable
KIND, that is entirely unrelated to any variable in the enclosing scope.

There may be some difficulties because implied DO's are not presently
scoping units.  It may fail altogether, because of the weight of
complexity, if putting an explicit declaration into an implied DO
requires it to be a scoping unit, whereas leaving out the declaration
prevents the implied DO from being a scoping unit.  It may, however,
at least be worth thinking about.

Best regards,
Van Snyder