From malcolm@nag.co.uk Wed Nov 4 20:39:59 1992 Received: from ben.uknet.ac.uk by dkuug.dk with SMTP id AA00989 (5.65c8/IDA-1.4.4j for ); Wed, 4 Nov 1992 20:39:59 +0100 Received: from eros.uknet.ac.uk by ben.uknet.ac.uk via UKIP with SMTP (PP) id ; Wed, 4 Nov 1992 19:39:46 +0000 Received: from num-alg-grp.co.uk by eros.uknet.ac.uk via JANET with NIFTP (PP) id <27214-0@eros.uknet.ac.uk>; Wed, 4 Nov 1992 19:39:49 +0000 Received: from jupiter.nag.co.uk (apollo) by nags2.nag.co.uk; Wed, 4 Nov 92 19:39:15 GMT From: Malcolm Cohen Message-Id: <7289.9211041938@jupiter.nag.co.uk> Subject: Re: (SC22WG5.243) Re: S20/58 To: bill@amber.ssd.csd.harris.com (Bill Leonard) Date: Wed, 4 Nov 92 19:38:51 WET Cc: JLS@liv.ac.uk, SC22WG5@dkuug.dk In-Reply-To: <9211041814.AA05687@amber>; from "Bill Leonard" at Nov 4, 92 1:14 pm X-Charset: ASCII X-Char-Esc: 29 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. > Making blanks in FORMATs significant is a completely unnecessary change. > There is no ambiguity involved, so why do it? It would only make life > infinitely harder for both implementors and users. It is easy to see that you believe that having significant blanks in free-form source is a bad idea; after all, they are not needed for ambiguity resolution (if they were, fixed-form source would not work!). Does it make life harder for the implementor and user? Speaking as an implementor who interpreted the blank-significance rules as applying to FORMAT statements, it is not hard at all. Not even a little bit. In fact, it is possibly slightly easier (in the context of a free-form lexer, not a fixed-form lexer) than allowing insignificant blanks; but I do not put forward this "ease of implementation" argument as any difference is far too trivial. 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. 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. Once again, the question is not about runtime format specifications, we are (I assume) all agreed that blanks cannot be significant in such (except in embedded char context blah blah). The question is whether we choose to have FORMAT statements consistent with other statements or with runtime format specifications. -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)