Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

is following code legal ?

86 views
Skip to first unread message

Lynn McGuire

unread,
Oct 19, 2021, 5:27:15 PM10/19/21
to
is following code legal ?

double precision a, b, c, d
double precision x
a = b = c = d = 0
...
x = 11.0
a = b = c = d = x / 2.0

The gFortran 12.2.0 in Simply Fortran does not like it all.

Thanks,
Lynn

Lynn McGuire

unread,
Oct 19, 2021, 5:27:44 PM10/19/21
to
The gFortran is 11.2.0, not 12.2.0.

Thanks,
Lynn

Thomas Koenig

unread,
Oct 19, 2021, 5:28:48 PM10/19/21
to
Lynn McGuire <lynnmc...@gmail.com> schrieb:
> is following code legal ?
>
> double precision a, b, c, d
> double precision x
> a = b = c = d = 0

No.

a = b is an assignment statement, not (like in C) an expression.

Lynn McGuire

unread,
Oct 19, 2021, 5:41:28 PM10/19/21
to
Was the multiple equals usage ever legal ? I would swear that I used
this back in the Fortran IV days in the middle 1970s.

Lynn

jfh

unread,
Oct 19, 2021, 6:13:29 PM10/19/21
to
My copy of McCracken' "A Guide to Fortran IV Programming" (2nd ed 1972) does not mention that syntax for assignment statements. The f66 standard does not allow it. But then and now some compilers offer extensions to the standard.

Lynn McGuire

unread,
Oct 19, 2021, 6:47:18 PM10/19/21
to
On 10/19/2021 4:27 PM, Lynn McGuire wrote:
From Open Watcom FORTRAN 77 Language Reference:
https://www.os2site.com/sw/dev/openwatcom/manuals/f77lr.pdf

8.6 Extended Assignment Statement
Open Watcom FORTRAN 77 supports an extension to the FORTRAN 77
assignment statement, namely
the extended assignment statement.
v = v = v = ... = v = e
1 2 3 n
where:
v’i must be one of the following:
1. Variable names or array element names of type INTEGER, REAL, DOUBLE
PRECISION, COMPLEX or double precision complex (COMPLEX*16).
2. Variable names or array element names of type LOGICAL.
3. Character variable names, character array elements, or character
substrings.
e must be one of the following and must follow the rules of the
arithmetic, logical or character
assignment statements:
1. An arithmetic expression.
2. A logical expression.
3. A character expression.
The extended assignment statement is equivalent to the following
individual statements.

v = e
n
v = v
n-1 n
.
.

.
v = v
2 3
v = v
1 2

Thanks,
Lynn

Beliavsky

unread,
Oct 19, 2021, 7:26:08 PM10/19/21
to
It's not Fortran, and Intel Fortran and g95 also reject it.

Dick Hendrickson

unread,
Oct 19, 2021, 11:02:52 PM10/19/21
to
It was never standard, but was a rare-ish extension in the 60s and early
70s. It's ambiguous with something like

R = I = 3.14

Should R be 3 or 3.14?

Dick Hendrickson

Lynn McGuire

unread,
Oct 19, 2021, 11:04:14 PM10/19/21
to
That would be nasty.

Thanks,
Lynn

Robin Vowels

unread,
Oct 19, 2021, 11:20:50 PM10/19/21
to
On Wednesday, October 20, 2021 at 8:27:15 AM UTC+11, Lynn McGuire wrote:
> is following code legal ?
.
No.
The fragment is not even legal in PL/I, which does allow multiple
assignments.
Its assignments are of the form
a, b, c, ... z = expression;
.
Algol 60 also permits multiple assignments of the form
a := b := c := expression;
.

Gary Scott

unread,
Oct 20, 2021, 1:05:51 AM10/20/21
to
Horrid!

gah4

unread,
Oct 20, 2021, 3:08:25 AM10/20/21
to
On Tuesday, October 19, 2021 at 8:20:50 PM UTC-7, Robin Vowels wrote:
> On Wednesday, October 20, 2021 at 8:27:15 AM UTC+11, Lynn McGuire wrote:
> > is following code legal ?
> .
> No.
> The fragment is not even legal in PL/I, which does allow multiple
> assignments.
> Its assignments are of the form
> a, b, c, ... z = expression;

Even worse, PL/I allows statements like:

a=b=c=d=1;

where the first = is an assignment, and the rest are the relational operator.

However, the comma form makes it (more) obvious that it is assigning
one value to all, and not propagation right to left.

In C, and in the Watcom documentation above, the assignments are right
to left, including any conversions done along the way.

In C, if you do:

int i, j;
float x, y;
j=x=i=y=3.5;

then y=3.5, and the rest 3, as you expect for right to left assignment,
and no warnings from gcc.

If you do:

x=i=y=j=3.5;

then gcc gives a warning on converting the constant.

Java will catch this without a cast, as it is a narrowing conversion.




John Collins

unread,
Oct 31, 2021, 12:48:46 PM10/31/21
to

John Collins

unread,
Oct 31, 2021, 1:02:47 PM10/31/21
to
On Tuesday, October 19, 2021 at 10:27:15 PM UTC+1, Lynn McGuire wrote:
> is following code legal ?
>
> double precision a, b, c, d
> double precision x
> a = b = c = d = 0
> ...
> x = 11.0
> a = b = c = d = x / 2.0
>

Yes and no. Mostly no.

This construct IS valid in MPX (Gould-SEL) extended FORTRAN 77 and we have seen it many times. As far as I know it isn't valid anywhere else and is not in any standard I can find. MPX FORTRAN was widely used for aircraft simulators, power-plant simulators and for real-time tasks like tracking radar controllers. The original 10K series ECL machines must by now be nearly all dead (I helped kill half a dozen of them), but Gould-SEL wrote emulators to keep the codes alive. So if you like flying in aircraft or using electricity you may still depend on these codes.

There are two possible meanings of the expression a = b = c

b = c
a = b

or

a = c
b = c

The Gould-SEL codes use the second interpretation, which means that the right-hand side value doesn't get changed in type or kind in the multiple assignment.

We even put a command into fpt to get rid of them.

Best wishes,

John
0 new messages