From malcolm@brackley.nag.co.uk Thu Mar 30 18:14:19 2000 Received: from brackley.nag.co.uk ([62.232.54.10]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id SAA27178 for ; Thu, 30 Mar 2000 18:14:19 +0200 (CEST) (envelope-from malcolm@brackley.nag.co.uk) Received: (from malcolm@localhost) by brackley.nag.co.uk (8.9.2/8.9.2) id RAA76601 for SC22WG5@dkuug.dk; Thu, 30 Mar 2000 17:13:20 +0100 (BST) (envelope-from malcolm) From: Malcolm Cohen Message-Id: <200003301613.RAA76601@brackley.nag.co.uk> Subject: Re: (SC22WG5.1751) Interpretation 001 To: SC22WG5@dkuug.dk Date: Thu, 30 Mar 2000 17:13:19 +0100 (BST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Lawrie Schonfelder said: >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. Yes, but (currently) implied DO loops are not scoping units - otherwise this question would not have arisen. That is why I lean to the view that (...,I=1,n) does create a symbol "I" (and thus an entity with the name "I") in the current scoping unit - not just in the DO loop. Symbols have a lifetime of a scoping unit, at various points in that scoping unit they may refer to different entities. I object to having to create a symbol in order to partially analyse the module and then having to pretend that it isn't there for the rest of the analysis; basically, this means adding yet-another-pass to the analyser - just for cruddy old implied-DO loops. The current suggested answer seems to have all the pain (of making implied-DO loops into scoping units) plus some extra pain (at least if you want to check the program against the restrictions in the standard), for less gain than actually making implied-DO loops into scoping units. I certainly find Lawrie's suggestion (viz "make implied-DO loops into scoping units") more elegant than the current suggested answer; but even Lawrie's suggestion has a couple of problems: (1) there is no lexical marker for the beginning of these implied-DO loops [unlike other scoping units] (2) it might be a bit big for an interpretation (3) it would introduce an inconsistency between the treatment of i/o-implied DO loops and other implied-DO loops [though perhaps not much of one] (4) no way to specify bigger-than-default loop variables [I don't think this is a problem yet, though it may become one in the future - either we invent syntax for F2002 or we declare the loop index to be of the largest integer type rather than the default integer type; cf what we do for BOZ constants in DATA statements] None of these seem insurmountable though. Kurt's suggestion (essentially, "only export things explicitly declared in some way") is also a good one, though it does not address the host association part of the question. It is also an incompatible change, though whether people really write things like MODULE m INTEGER :: x = KIND(y) END in order to deliberately export default integer X, default real Y and intrinsic KIND is somewhat open to debate. In a way the question is what kind of badly written code do we want to bless? Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)