From Craig_Dedo@execpc.com Fri Mar 31 18:11:00 2000 Received: from mailgw02.execpc.com (sendmail@mailgw02.execpc.com [169.207.3.78]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id SAA30909 for ; Fri, 31 Mar 2000 18:10:59 +0200 (CEST) (envelope-from Craig_Dedo@execpc.com) Received: from execpc.com (kronos-2-171.mdm.mkt.execpc.com [169.207.86.109]) by mailgw02.execpc.com (8.9.1) id KAA20024; Fri, 31 Mar 2000 10:10:43 -0600 Message-ID: <38E4CDC7.802CD552@execpc.com> Date: Fri, 31 Mar 2000 10:09:43 -0600 From: "Craig T. Dedo" Reply-To: "Craig T. Dedo" Organization: Elmbrook Computer Services X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Reid CC: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.1763) Second revision of proposal for Interpretation 001 References: <200003311422.QAA30578@dkuug.dk> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms11E959F13E992A52152C3780" This is a cryptographically signed message in MIME format. --------------ms11E959F13E992A52152C3780 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear John: This sounds good, as far as it goes. I do have some questions: 1. Are you taking ownership of this particular interpretation? From the text in your introductory paragraph it appears that you are. 2. What about the KIND type parameter of the index variable? Is it always default KIND? Is the KIND type parameter derived from the values of the other variables in the statement? Is it always of the KIND with the largest possible value? 3. If there is a variable declared in the scoping unit with the same name and it is suitable for use as an index variable: a. Is the declared variable used, or b. Is the index variable different from the declared variable? Example: INTEGER(KIND=8) :: I ! On this processor, KIND=8 specifies 64-bit binary arithmetic. REAL, DIMENSION :: A(10,10), X(10) ! Processing during which I is assigned the value of 10 billion (10**9) and has that value immediately prior to the following statement. FORALL (I=1:10) A(I,I) = X(I) After the execution of the FORALL statement, does I have the value 10 or 10 billion? Or, is I undefined? FWIW, I would prefer option b, so that I after the FORALL statement has the value 10 billion. 4. Should we have a straw vote, either by e-mail or at the next J3 meeting on the questions in item 2 and 3? John Reid wrote: > Thank you for your further comments. I have added Henry's suggestion > that text for FORALL is needed. Malcolm's comment convinces me that the > edit really is needed. When this text was written (by me, as it > happens), I am sure that the committee did not expect an implied-DO in > an array constructor to provide an implicit declaration of a variable > with the same name in the scoping unit containing the statement. Had > this been so, different (simpler) text would have been appropriate. > > Over to J3 at its meeting in May. > > John Reid. > > ............................................... > > Date: 31st March 2000 > To: J3 > From: John Reid > Subject: Interpretation 001 > > Here are drafts for the ANSWER and EDITS sections of 001. They are > based on the email from Henry Zongaro. Also, I propose that the > addendum be removed. > > ANSWER: > The implied-DO variable is not visible to the using program. > 14.1.3 Statement Entities states, in part, that > > The name of a variable that appears as the DO variable of an > implied-DO in a DATA statement or an array constructor has a scope > of the implied-DO list. It has the type and type parameter that it > would have if it were the name of a variable in the scoping unit > that includes the DATA statement or array constructor and this type > must be integer. > > The words "would have if it were" were intended to convey > the idea that the existence of an array constructor or data implied-DO > variable does not actually cause an associated variable in the scoping unit > to come into existence. > > Also, the following text appears in the same section (281:12-14): > > If the name of a global or local entity accessible in the scoping unit of > a statement is the same as the name of a statement entity in that > statement, the name is interpreted within the scope of the statement > entity as that of the statement entity. > > The word "If" here implies that there need not be any such > global or local entity with the same name as that of the statement entity. > > The first edit makes this clear. The second edit makes the same point > for FORALL statements and constructs. > > EDITS: > Page 280, Clause 14.1.3, at the end of the first paragragh (280:44) add: > > The appearance of a name as the DO variable of an implied-DO in a > DATA statement or an array constructor is not an implicit > declaration of a variable whose scope is the scoping unit that > contains the statement. > > Page 281, Clause 14.1.3, at the end of the second paragraph [281:4] add: > > The appearance of a name as an index-name in a FORALL statement or > FORALL construct is not an implicit declaration of a variable whose > scope is the scoping unit that contains the statement or construct. -- ---------- Sincerely, Craig T. Dedo Internet: Craig_Dedo@execpc.com Elmbrook Computer Services Voice Phone: (262) 783-5869 17130 W. Burleigh Place Fax Phone: (262) 783-5928 Brookfield, WI 53005-2759 Disclaimer: These opinions are mine alone. USA They do NOT represent any organization. "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin (1759) --------------ms11E959F13E992A52152C3780 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhBG4ZWptBYAxojLrCfrLq/JMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDMxNDAwMDAw MFoXDTAxMDMxNDIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUNyYWlnIFQuIERlZG8xJDAiBgkqhkiG 9w0BCQEWFWNyYWlnX2RlZG9AZXhlY3BjLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAw43PVl7mAyQaKBzZ2L83NbgE6EhdKcbP0ha/wnQV63qHlTOvdG7xd8GL5m1f9LgZRbfW Csm4HhLMgtCcx0C/8iVfCWEPIJlmbuYIMKM8eMhKWBpWcPvyJVfOtx038+TInEAbJqCKG32z mfU+6O7fC53BgdSU7IZo4IeblPGiKNsCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhY2UzOGMyZjg4NzBiYWY2Y2Y0ZGUxMTQ5OTZhMWJhNDdmOWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAZa760CJnD2WGM2L4BFgX6CuhU47i7GHz8Vjjza1snB5aAHsh hBdFtKcMl/X/5TONQh9EEUU6hX+Z7YKkh1R2KPHIJRpoqruKbG9tZ9o/gzuoZ/wJ2ybE4/kU ga2VTk/9calArW7wLssucNg64O/cwEkIK5ZquC+e509hrtgLZSgwggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBG 4ZWptBYAxojLrCfrLq/JMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMzMxMTYwOTQzWjAjBgkqhkiG9w0BCQQxFgQUYmxChxaG Zw7U05ZeowTAeuttZRUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYAx0nQpuNMbmMb3yYuC6s/Y3S3tk+AiYyqbZajjUwxRBmISzC1pGVYqnaIzVHae HivpAQWtcJB4oXHDe0dPLdb0Ks312zrJuuqmC8/wQEX7zSJwZ2tYXP6NDoawg8oiYc1fCwKr SKo+jTwbe4Q2cu1IllVbUmRJoHHh6kiI7NFNEQ== --------------ms11E959F13E992A52152C3780--