From hirchert@ccs.uky.edu Thu Mar 30 17:26:42 2000 Received: from mailhost.ccs.uky.edu (mailhost.ccs.uky.edu [128.163.209.59]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id RAA26942 for ; Thu, 30 Mar 2000 17:26:41 +0200 (CEST) (envelope-from hirchert@ccs.uky.edu) Received: from hirchert (hirchert.ccs.uky.edu [128.163.209.36]) by mailhost.ccs.uky.edu (8.9.1/8.9.1) with SMTP id KAA02309; Thu, 30 Mar 2000 10:26:48 -0500 (EST) Message-Id: <3.0.5.32.20000330102640.007ec240@perseus.ccs.uky.edu> X-Sender: hirchert@perseus.ccs.uky.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 30 Mar 2000 10:26:40 -0500 To: j.l.schonfelder@liverpool.ac.uk From: "Kurt W. Hirchert" Subject: Re: (SC22WG5.1751) Interpretation 001 Cc: SC22WG5@dkuug.dk In-Reply-To: <200003301006.MAA25520@dkuug.dk> References: <200003291659.SAA22556@dkuug.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:02 AM 3/30/00 +0100, Lawrie Schonfelder wrote: >I would be happy to have the inclusion of a name as an implied DO index >defined as an explicit declaration of that name as an integer within the >scope of the implied do. I would also have it independent of any declaration >of the same name in the containing scope. As in host association within the >implied do scope the index variable masks any variable of the same name from >the outer scope. This would have been clean and consistent with every other >language I know of that has nested scopes. It would be exactly similar to >host association scoping rules. I see two potential traps in this: 1. Note that I/O implied DO loops _don't_ use a different variable, so be careful about how generally you state this. (If you were to make I/O implied DO loops use different variables, you could break existing standard-conforming f77 and f90 programs.) 2. There remains the question of which KIND of integer the DO index is declared to be. Default integer may be inadequate or inappropriate. I suppose we could have invented some convention such as the DO index taking its KIND from that of the initial value expression, but given that we didn't, we must consider the cost of making an incompatible change to the language (i.e., one that potentially would render conforming programs nonconforming). I am relatively comfortable with "fixing" the standard to eliminate phantom exports, because I seriously doubt that anyone has caused one intentionally (other than in test programs). I am much less comfortable with the specific changes you propose, because they have other effects that do have the potential to invalidate real programs. -- Kurt W. Hirchert hirchert@ccs.uky.edu Center for Computational Sciences +606-257-8748