Compulsory spaces in free source form 
Author Message
 Compulsory spaces in free source form

The f95 standard requires a blank between a statement keyword, name,
constant or label and an adjacent name, constant or label in free source
form, and it's obvious why if, for example, a constant has a name. But
it's a pity that the rule prevents things like STOP'Now' where ambiguity
is impossible. (Some compilers e.g. g95 catch this error, others don't.)

But there are cases like PRINT* and STOP666 where the * or the 666 seems
not to be a name, constant or label (666 in some contexts is a constant
but here it's a string of up to 5 digits). The blank is then presumably
not needed, even though STOP666 looks as if it could also be the name
of a variable. F95 compilers disagree on how they treat the program
below; is it standard-conforming in free source form?

    STOP666 = 666
    PRINT*,'STOP666 =',STOP666
    STOP666
    END

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand



Mon, 19 Mar 2007 06:06:31 GMT  
 Compulsory spaces in free source form
...

Quote:
> But there are cases like PRINT* and STOP666 where the * or the 666 seems
> not to be a name, constant or label (666 in some contexts is a constant
> but here it's a string of up to 5 digits). The blank is then presumably
> not needed, even though STOP666 looks as if it could also be the name
> of a variable. F95 compilers disagree on how they treat the program
> below; is it standard-conforming in free source form?

>     STOP666 = 666
>     PRINT*,'STOP666 =',STOP666
>     STOP666
>     END

That has always been one of my main discomforts about 3 of the
document.  The rules ought to be formally specified and they are
not.  Instead you get an informal description of what the souce
forms require.  So, though it is not something I would ever write
or necessarily expect to work, the above program *looks* conforming
to me.  The standard to vague, but that *seems* to be the correct
conclusion.

I would prefer that free source form require a space anywhere two
tokens are intended and the space free version matches the form of
some other token (like an identifier).  That way there would be more
instances where the implementor could just use a naive lexer and be
successful.  In other words, I would prefer that free source form
require a space in the STOP statement above.  But, the standard
doesn't do that.  :-(

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare



Mon, 19 Mar 2007 06:38:19 GMT  
 Compulsory spaces in free source form

Quote:

> The f95 standard requires a blank between...

> But there are cases like PRINT* and STOP666 where the * or the 666 seems
> not to be a name, constant or label....
...
>     STOP666 = 666
>     PRINT*,'STOP666 =',STOP666
>     STOP666
>     END

I think you've got it analyzed just right and that the code shown is
legal in free source form.  I also think it is just plain silly that
this is legal, but you didn't ask about that.  :-)

I'm fairly sure I recall an interp to this effect for the print*
case, but there are enough interps, some with confusing titles,
that it is a pain to plow through them all ... ah heck, I'll look
anyway.... Amazing, that one had a clear title, so it didn't take
long to find,  Copied below. It doesn't directly mention your
example with STOP, but I think the same logic would apply.  Though
hmm... that would make the proposal (which has been made) to
extend STOP by allowing expressions there an incompatibility instead
of an extension.... Anyway.

NUMBER: 000002
TITLE: Free source form requirement for blank in PRINT statement
KEYWORDS: Free source form, PRINT, blank
DEFECT TYPE: Interpretation
STATUS: Included in corrigendum/complete

QUESTION:

Consider the following PRINT statement form:  PRINT"(I5)",5 Section 3.3.1 of the fortran 95 standard states:

  A blank shall be used to separate names, constants, or labels from
  adjacent keywords, names, constants, or labels.

  NOTE 3.3
  For example, the blank[s] after ... READ ... [is] required in the
  following:

  ...
  READ 10
  ...

Although the sentence preceding R420 is somewhat confusing in that it uses the phrase "a sequence of characters, DELIMITED by either apostrophes or quotation marks", the syntax rule itself is clear that the " or ' delimiting characters are part of the <char-literal-constant> syntax.  The first sentence on the top of page 36 then clarifies that although the delimiter characters are a part of the syntax, they are not a part of the value.

Section 3.2 makes it clear that a character literal constant is a token. Section 3.2.5 describes delimiters but does not include either " or ' because it is describing delimiters for lists.

Thus, it seems clear that in free source form a blank is required between the keyword PRINT and the character literal constant containing the format list but there is also some disagreement on this point among existing Fortran processors.

(1) In free source form, is a blank required between the keyword
    PRINT and the character literal constant containing the format
    specification?

(2) Also, for clarification, in free source form, is a blank required
    between the keyword PRINT and the asterisk that represents the
    list-directed output specifier?

ANSWER:

(1)  Yes.  The analysis in the QUESTION is correct.  Since PRINT is a
     keyword, when the format specification is a character literal
     constant, the blank is required between the keyword PRINT and
     the format specifier.

(2)  No.  Since PRINT is a keyword, according to the cited rule in
     3.3.1, the asterisk would have to be a name, a constant, or a
     label in order for a blank to be required to separate PRINT from
     the asterisk.  By 3.2.1, an asterisk is not a name.  By 3.2.2,
     an asterisk is not a constant.  And by 3.2.4, an asterisk is not
     a statement label.  Yes, an asterisk may be used as a dummy
     argument alternate return specifier representing a statement
     label but that usage is irrelevant to the PRINT statement.
     Therefore, since an asterisk is none of the three items that
     must be separated from PRINT by a blank, the blank is not
     required.

EDITS: None.

SUBMITTED BY: Larry Rolison /{*filter*} Hendrickson

HISTORY: 97-238    m143 Submitted
         01-151r1  m156 Passed unanimously by J3 meeting
         01-224r1  m157 Passed by J3 letter ballot
         WG5/N1435 Passed by WG5 ballot
         01-Nov    wg5  no edits for corrigendum #2 => processing complete

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain



Mon, 19 Mar 2007 06:45:23 GMT  
 Compulsory spaces in free source form

Quote:


> ...
>> But there are cases like PRINT* and STOP666 where the * or the 666 seems
>> not to be a name, constant or label (666 in some contexts is a constant
>> but here it's a string of up to 5 digits). The blank is then presumably
>> not needed, even though STOP666 looks as if it could also be the name
>> of a variable. F95 compilers disagree on how they treat the program
>> below; is it standard-conforming in free source form?

>>     STOP666 = 666
>>     PRINT*,'STOP666 =',STOP666
>>     STOP666
>>     END
> [...]  So, though it is not something I would ever write
> or necessarily expect to work, the above program *looks* conforming
> to me.  The standard to vague, but that *seems* to be the correct
> conclusion.

Well, here I am already wrong.  I read the wrong paragraph and
reached the wrong conclusion.  The right quotation is (F95 [actually
j3/97-007/r2],3.1.1):

   A blank shall be used to separate names, constants, or labels
   from adjacent keywords, names, constants, or labels.

Since STOP is a keyword, and 666 is a label, the space between them
is indeed required.

Whew!  That's what I wanted.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare



Mon, 19 Mar 2007 06:47:27 GMT  
 Compulsory spaces in free source form

Quote:

> Well, here I am already wrong.  I read the wrong paragraph and
> reached the wrong conclusion.  The right quotation is (F95 [actually
> j3/97-007/r2],3.1.1):

>    A blank shall be used to separate names, constants, or labels
>    from adjacent keywords, names, constants, or labels.

> Since STOP is a keyword, and 666 is a label, the space between them
> is indeed required.

The correct section is 3.3.1.  Not only am I reading selectively,
my fingers are misbehaving.  The weather is gloomy today too.

  :-(

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare



Mon, 19 Mar 2007 06:50:07 GMT  
 Compulsory spaces in free source form
...
Quote:
> >>     STOP666

...

Quote:
> Since STOP is a keyword, and 666 is a label, the space between them
> is indeed required.

I'm afraid that, although the 666 looks sort of like a label, it isn't
one. It is just a <stop-code>. Similarity of syntax isn't enough to
make stop codes and labels the same thing.  And besides, there is
even a syntactic difference in that a label is constrained to have
at least one non-zero digit, while a stop-code is not.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain



Mon, 19 Mar 2007 06:55:32 GMT  
 Compulsory spaces in free source form

Quote:



>>...

>>>But there are cases like PRINT* and STOP666 where the * or the 666 seems
>>>not to be a name, constant or label (666 in some contexts is a constant
>>>but here it's a string of up to 5 digits). The blank is then presumably
>>>not needed, even though STOP666 looks as if it could also be the name
>>>of a variable. F95 compilers disagree on how they treat the program
>>>below; is it standard-conforming in free source form?

>>>    STOP666 = 666
>>>    PRINT*,'STOP666 =',STOP666
>>>    STOP666
>>>    END

>>[...]  So, though it is not something I would ever write
>>or necessarily expect to work, the above program *looks* conforming
>>to me.  The standard to vague, but that *seems* to be the correct
>>conclusion.

> Well, here I am already wrong.  I read the wrong paragraph and
> reached the wrong conclusion.  The right quotation is (F95 [actually
> j3/97-007/r2],3.1.1):

>    A blank shall be used to separate names, constants, or labels
>    from adjacent keywords, names, constants, or labels.

> Since STOP is a keyword, and 666 is a label, the space between them
> is indeed required.

> Whew!  That's what I wanted.

Doesn't all of this mean that lexing free source is much easier than
lexing fixed source? In particular, does it obviate the need for Sale's
algorithm?

cheers,

Rich

--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]



Mon, 19 Mar 2007 07:00:11 GMT  
 Compulsory spaces in free source form
...

Quote:
> Doesn't all of this mean that lexing free source is much easier than
> lexing fixed source? In particular, does it obviate the need for Sale's
> algorithm?

Unfortunately, no.  (And, as Maine pointed out, I was wrong
about being wrong.  Though, I think the issue this time is that
the committee didn't write what they intended.  That's why
a formal spec would be nice).

Anyway, Sale's algorithm is less often needed.  For example,
the required spaces of:

   do i=1,10
   do i=1.10

make the error in the second obvious and the need for Sale's
algorithm in the first is only as verification or an aide in generating
messages.  If you write:

   doi=1,10

The use of Sale's algorithm will assist you in the suspicion that the
intent was a do loop and the programmer forgot the necessary space.

However, for some other cases Sale's algorithm is still required.

   if(123.gt.4)then=5
   if(123-4) = 5

The latter you recognize from Sales algorithm as an assignment since
there are no instances in the statement of open context commas, no
instances in the statement of a close parenthesis followed immediately
(disregarding spaces) by a letter or digit, and there is an open context
assignment operator.  The first you recognize as an IF statement since
there is a close parenthesis followed immediately by a letter.  Similarly
for

   write(5)=5
   write(5) 5

The second has no open context assignment operator and does have
a close parenthesis folowed by a digit: it must begin with a keyword.

And so on.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare



Mon, 19 Mar 2007 07:25:05 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. long free source form lines

2. Free source form by file extension

3. Free source form with Fortran 77 compilers

4. used space 0, free space 0

5. Determining free-form or fixed-form reference format.

6. Converting fixed form (F77) into free form (F90)

7. Print single space on form templete

8. How do we get round compulsory browsing

9. Remove spaces form text

10. open-source project to make a space combat/trading game

11. Space Invaders Asm source (27k zip file)

12. Getting Volume Size/Free Space VIA appleevent

 

 
Powered by phpBB® Forum Software