From j.l.schonfelder@liverpool.ac.uk Thu Mar 30 10:58:36 2000 Received: from mailhub2.liv.ac.uk (mailhub2.liv.ac.uk [138.253.100.95]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id KAA25091 for ; Thu, 30 Mar 2000 10:58:31 +0200 (CEST) (envelope-from j.l.schonfelder@liverpool.ac.uk) Received: from pcmail1.liv.ac.uk ([138.253.252.13]) by mailhub2.liv.ac.uk with esmtp (Exim 2.12 #1) id 12aamV-0002W7-00; Thu, 30 Mar 2000 09:58:23 +0100 Received: from [138.253.102.118] (helo=pc102118.liv.ac.uk) by pcmail1.liv.ac.uk with smtp (Exim 2.12 #1) id 12aamU-0003oI-00; Thu, 30 Mar 2000 09:58:22 +0100 From: Lawrie Schonfelder Reply-To: j.l.schonfelder@liverpool.ac.uk To: "Kurt W. Hirchert" Cc: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.1742) Interpretation 001 In-Reply-To: <3.0.5.32.20000329104528.0082a580@perseus.ccs.uky.edu> Message-ID: Date: Thu, 30 Mar 2000 09:58:22 +0100 (GMT Daylight Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.5 Build (43) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Kurt, you have just underlined my point. My a.&b. are my view of what we should have done. You have just provided the standard legalise that now indicates why we have a mess. A mess that I think should be fixed rather than relying on the Jesuitical arguing from past authority when past authority is flawed. I also understand the reasons for the "public" default. A position I was strongly in favour of at the time. It is also true that subsequent use of F90/95 suggests that this was perhaps an unwise decision even with the novice programmer in mind. It makes simplistic modules easy but it also makes it easier for novices and non-novice programmers to shoot themselves in the foot. On Wed, 29 Mar 2000 10:45:28 -0500 "Kurt W. Hirchert" wrote: > 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 -- Lawrie Schonfelder Director, Computing Services Dept. The University of Liverpool, UK, L69 7ZF Phone: 44(151)794 3716, Fax: 44(151)794 3759