From bill@amber.ssd.csd.harris.com Wed Nov 4 11:09:34 1992 Received: from travis.csd.harris.com by dkuug.dk with SMTP id AA03190 (5.65c8/IDA-1.4.4j for ); Wed, 4 Nov 1992 22:12:22 +0100 Received: from amber.ssd.csd.harris.com by travis.csd.harris.com (5.61/harris-5.1) id AA17037; Wed, 4 Nov 92 16:09:38 -0500 Received: by amber (5.61/CX/UX-5.0) id AA22822; Wed, 4 Nov 92 16:09:34 -0500 Date: Wed, 4 Nov 92 16:09:34 -0500 From: bill@amber.ssd.csd.harris.com (Bill Leonard) Message-Id: <9211042109.AA22822@amber> To: malcolm@nag.co.uk Cc: JLS@liv.ac.uk, SC22WG5@dkuug.dk In-Reply-To: Malcolm Cohen's message of Wed, 4 Nov 92 19:38:51 WET <7289.9211041938@jupiter.nag.co.uk> Subject: (SC22WG5.243) Re: S20/58 X-Charset: ASCII X-Char-Esc: 29 > From: Malcolm Cohen > Date: Wed, 4 Nov 92 19:38:51 WET > Dear Bill, >> This would require that the runtime system, which is where FORMATs are >> interpreted, would have to know how the source was compiled. Even worse, > No it would not, the question is on FORMAT statements not runtime formats. So now you want to make the interpretation of a FORMAT different depending on whether it came from a FORMAT statement versus a runtime format? That would certainly complicate the description of how format specifications are interpreted. Furthermore, I disagree with you that the issue is just on FORMAT statements. The text on page 135 beginning "Blank characters may precede ..." talks about format *specification*, not format statement. Therefore, this rule must apply to all format specifications, regardless of their source. Treating FORMAT statements differently also complicates implementations that take the very simplistic approach of just storing the format specification from the FORMAT statement as a character string that gets passed to the runtime system. Such an implementation would now be *required* to preprocess the specification to remove insignificant blanks (or indicate by some other means to the runtime system whether or not to treat blanks as significant). > On the question of the user, to my mind the inconsistency of having > significant blanks in every statement in free-form source EXCEPT format > statements makes it harder for the user, not easier. It certainly makes > it look as if the subcommittee of J3 which was in charge of FORMATs did > not believe in (and thus did not go along with) the significant blank > theory which the rest of the committee accepted. I think this is a red herring. FORMAT statements have their own syntax anyway, including special rules about where commas can be omitted, the appearance of Hollerith strings, etc. They are also special in that no processor is *required* to diagnose any syntactic errors in a FORMAT statement. I think it would be much harder for the user if Chapter 10 had to describe *two* format-specification syntaxes: one for FORMAT statements and one for character-string formats. FORMATs are special beasts, and always will be, because of the peculiarity that they can be constructed at runtime as well as appearing as "special constants" in the source. > There is no functionality lost by requiring significant blanks in this case. > It has been put forward in the past that what IS lost is the consistency > between runtime and compile-time FORMATs. It is my view that this is spurious, > since a FORMAT longer than 126 characters (much less in fixed-form) cannot be > the same, since the statement version requires continuation lines with special > continuation characters whereas the runtime specification not only does not > require continuation lines but does not allow any continuation characters. You are confusing the construction of the format specification from a FORMAT statement with the contents of that statement. A FORMAT statement can be compiled nearly identically to compiling a character string, which may also be continued across multiple source lines. Would you argue that blanks should be significant in character strings because they can be continued? I hope not! Throughout the F90 (and F77) standard, the format-specification part of a FORMAT statement has been considered identical to a character-string context. We just happened to miss one place, that's all. Let's not go overboard and completely change everything, which will probably end up creating incompatibilities with F77. Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.csd.harris.com --------------------------------------------------------------------------- Prism: A place for light waves that commit minor refractions. ---------------------------------------------------------------------------