From hirchert@ccs.uky.edu Wed Mar 29 17:46:19 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 RAA22333 for ; Wed, 29 Mar 2000 17:46:18 +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 KAA10070; Wed, 29 Mar 2000 10:45:38 -0500 (EST) Message-Id: <3.0.5.32.20000329104528.0082a580@perseus.ccs.uky.edu> X-Sender: hirchert@perseus.ccs.uky.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 29 Mar 2000 10:45:28 -0500 To: j.l.schonfelder@liverpool.ac.uk From: "Kurt W. Hirchert" Subject: Re: (SC22WG5.1742) Interpretation 001 Cc: SC22WG5@dkuug.dk In-Reply-To: <200003291331.PAA21683@dkuug.dk> References: <200003291300.PAA21560@dkuug.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 02:31 PM 3/29/00 +0100, Lawrie Schonfelder wrote: >On Wed, 29 Mar 2000 08:00:11 -0500 "Kurt W. Hirchert" >wrote: > > >I agree with most everything Kurt said. However, I have always thought that >the obviously sensible, as distinct from standard committee legalistic, >interpretation of things like implied do indecies is that >a. they have the scope of the implied do and >b. they are implicitly declared only in that scope not in the surrounding >host scope. I might agree that this would be a sensible behavior, but I have difficulty accepting it as an "obvious" interpretation when there is no text in the standard to suggest your point b, and, indeed, there is text which can be interpreted as directly contradicting it. As an error correction rather than an interpretation, one might be able to make an argument something like the following: 1. The rules for the scoping of array constructor implied DO are based on the DATA implied DO in FORTRAN 77. 2. In FORTRAN 77, it didn't matter if these rules conceptually created an implicitly declared variable in the host scoping unit, because there was nothing in the standard that required an implementation to assign storage or otherwise make that variable manifest. 3. Describing a localized implicit declaration would have required more text. 4. The creation of the variable in the host scoping unit can thus be seen as a benign side effect of keeping the text short rather than a desired consequence. 5. With the introduction of modules in Fortran 90, this side effect ceased to be benign, so the description should have been "corrected" to eliminate such implied DO variables from having any side effect on the environment around them. However, in case you think such an argument is "obvious", consider this: If you put IMPLICIT NONE in the module, you can't write those implied DO loops without explicitly declaring the DO variables in the module, even though the variables in the module will never be affected by the implied DO loops. If creation of module variables is necessary in the IMPLICIT NONE case, why should it be unnecessary in the default implicit rules case? > >I would go further and suggest that should an object of the same name be >declared implicitly or explicitly in the host scope it is a different entity, >i.e. that the rules of host association apply, as they would in any other >language with nested scopes. This is I fear a vane hope therefore Kurt's >final point is very well made. We probably got the default for public/private >the wrong way round in all but the most trivial of cases. I suppose that depends on what you believe the basis should be for establishing the language defaults. Fortran's tradition tends to be to choose convenience for novice programmers over safety for experienced programmers. For example, the novice programmer can use the default implicit rules to write small programs without ever writing a type declaration; the experienced programmer must explicitly add IMPLICIT NONE to forgo some of that convenience in the interests of greater safety. Similarly, making PUBLIC the default makes it possible for the novice programmer to make use of modules without ever explicitly coding PUBLIC or PRIVATE, but the experienced programmer needs to explicitly code a PRIVATE default to have better control over what is exported from a module. One can argue whether convenience or safety is the greater good, but choosing convenience was consistent with Fortran tradition. -- Kurt W. Hirchert hirchert@ccs.uky.edu Center for Computational Sciences +606-257-8748