From maine@altair.dfrc.nasa.gov Wed Jul 12 22:39:51 2000 Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id WAA57327 for ; Wed, 12 Jul 2000 22:39:47 +0200 (CEST) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP; Wed, 12 Jul 2000 13:39:12 -0700 Received: from altair.dfrc.nasa.gov ([130.134.129.8]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 35-62055U1500L100S0V35) with ESMTP id gov for ; Wed, 12 Jul 2000 13:39:11 -0700 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.9.3/8.9.3) id NAA01800; Wed, 12 Jul 2000 13:39:08 -0700 From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14700.55148.697900.682355@altair.dfrc.nasa.gov> Date: Wed, 12 Jul 2000 13:39:08 -0700 (PDT) To: SC22WG5@dkuug.dk Subject: (SC22WG5.1851) WG5 letter ballot on Fortran 95 interpretations In-Reply-To: <200006301432.QAA12998@dkuug.dk> References: <200006301432.QAA12998@dkuug.dk> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid John Reid writes: > The following Fortran 95 interpretations are being balloted: > > Yes No Number Title > > --- -X- 000067 Writing zeros Two separate reasons, either of which would merit a "no" vote. 1. Appropriateness. There is no defect here. Nothing here is unclear or internally inconsistent in the standard as published. This appears to be nothing more than an attempt to retroactively make a change to the language. This is not a proper thing to do in an interpretation. It sounds like an MTE....but the time for MTEs for f95 has passed by at least half a decade. Furthermore, the change is incompatable with f90 and with f95 as published. Both f90 and f95 explicitly required one form, while this change explicitly disallows that form and requires a different form. This interpretation makes *every* formerly conforming f95 processor now be non-conforming, and it makes any f90 or f95 program that depended on the f90 behavior now invalid. If such a change were made, it would merit mentioning in the list of incompatabilities in section 1. (It seems more pertinent than some of the things already listed there). 2. Technical error in the edits. The edits refer to the "constants" produced by formatted output. The term "constant" is inappropriate here. Formatted output produces sequences of characters - not constants. F90 interp 131 went to a lot of trouble to fix such incorrect usage of the term "constant". We should not re-break it. A constant has a type and type parameters - formatted output does not. The allowable forms of literal constants are not the same as the allowable forms of formatted output (notably, formatted output never includes kind type parameters). > -X- --- 000068 Asterisks as I/O units > > -X- --- 000069 What is a numeric character? > > -X- --- 000070 Asymmetry between constant specification and > initialization expressions > > -X- --- 000071 Character array constructors > > -X- --- 000072 Resolving generic procedure references > > -X- --- 000076 INTENT(IN) dummy arguments and implied DO loops > > -X- --- 000077 INTENT(IN) dummy arguments and NULLIFY > > -X- --- 000079 Pointer Assignment and Allocatable Arrays > > -X- --- 000080 Host association and the EXTERNAL attribute > > -X- --- 000082 Usage of BOZ literal constants > > -X- --- 000083 Scope of array-constructor implied-DO variable > > -X- --- 000084 Events that cause variables to be defined -- Richard Maine maine@altair.dfrc.nasa.gov