Working on some old, but commercially important code, we found DATA statements of the form, e.g.

DATA (c = 2.99792458D8, pi = 3.1415926536D0)

This compiles in the original VMS environment and (no surprise) under ifort and CVF. gfortran very reasonably doesn't like it.

However, this seems a more regular syntax than the standard. Does anyone know the history?

On Saturday, April 2, 2022 at 5:21:03 AM UTC+11, john.c...@simconglobal.com wrote:
> Working on some old, but commercially important code, we found DATA statements of the form, e.g.
>
> DATA (c = 2.99792458D8, pi = 3.1415926536D0)
>
> This compiles in the original VMS environment and (no surprise) under ifort and CVF. gfortran very reasonably doesn't like it.
..
Just change it to the standard.
..
> However, this seems a more regular syntax than the standard. Does anyone know the history?

On 01/04/2022 21:21, John Collins wrote:
> Working on some old, but commercially important code, we found DATA statements of the form, e.g.
>
> DATA (c = 2.99792458D8, pi = 3.1415926536D0)
>
> This compiles in the original VMS environment and (no surprise) under ifort and CVF. gfortran very reasonably doesn't like it.
>
> However, this seems a more regular syntax than the standard. Does anyone know the history?
>

Admittedly, I don't know the history!

IMHO however this DATA statement phenomenicaly has similarities with
a compiler specific version of the PARAMETER statement, and so I tried
the first example below.

GNU Fortran however likely fails to parse some "io-implied-do" objects
as we can see from the second example below. Not sure if I faced some
typo in the html page I found the statement of the second example or
it's another variant of a compiler specific DATA statement as well.

-------------------------------------------------------------------
$ cat data.f90 && gfc -DDATA=PARAMETER data.F90 && ./a.out
DATA (c = 2.99792458D8 , pi = 3.1415926536D0 )
PRINT *, c, pi
END
299792448. 3.14159274

-------------------------------------------------------------------
$ cat data2.f90 && gfortran -ffixed-form data2.f90
DATA ( S(I,I), I=1,4)/4.0/

!https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn85/index.html
! See that these two lines differ!
! DATA ( S(I,I), I=1,4)/4*1.0/, ( R(I,J), J=1,3), I=1,2)/6*1.0/
DATA ( S(I,I), I=1,4)/4*1.0/, ((R(I,J), J=1,3), I=1,2)/6*1.0/
END
data2.f90:1.15:

DATA ( S(I,I), I=1,4)/4.0/
1
Error: Syntax error in DATA statement at (1)
data2.f90:6.15:

DATA ( S(I,I), I=1,4)/4*1.0/, ((R(I,J), J=1,3), I=1,2)/6*1.0/
1
Error: Syntax error in DATA statement at (1)
$

On 02/04/2022 05:50, Ev. Drikos wrote:
> ...
>
> GNU Fortran however likely fails to parse some "io-implied-do" objects
> as we can see from the second example below. Not sure if I faced some
> typo in the html page I found the statement of the second example or
> it's another variant of a compiler specific DATA statement as well.
>
>

Oh, I forgot the array declarations. So, gfortran is ok!!!

On Friday, April 1, 2022 at 11:21:03 AM UTC-7, john.c...@simconglobal.com wrote:
> Working on some old, but commercially important code, we found DATA statements of the form, e.g.
> DATA (c = 2.99792458D8, pi = 3.1415926536D0)
> This compiles in the original VMS environment and (no surprise) under ifort and CVF. gfortran very reasonably doesn't like it.
It is not in VAX Fortran of 1984. Which VMS versions have it?

> However, this seems a more regular syntax than the standard. Does anyone know the history?

The regular syntax is in Fortran 66. Maybe earlier than that.

I do remember some strange things from CDC Fortran, especially with their use
of a 6 bit character set. Even so, I don't know that they would do that.

@gah4
> It is not in VAX Fortran of 1984. Which VMS versions have it?

We found this on Itanium, listing gives: COMPILER: VSI Fortran V8.3-104956-50P85
This is interesting because if it wasn't on VMS Fortran in 1984 then someone added it later. We found it in code which was running on Itanium VMS but dated from the 1980s or before.

I like the syntax - standard DATA statement syntax forces a special case handler for a general expression and this doesn't. It is not a major issue - no-one will change the DATA statement syntax now, but I am curious.

It is supported by DVF/CVF and ifort. Perhaps Steve Lionel can comment?

On Saturday, April 2, 2022 at 9:11:41 AM UTC-7, john.c...@simconglobal.com wrote:
> @gah4
> > It is not in VAX Fortran of 1984. Which VMS versions have it?

> We found this on Itanium, listing gives: COMPILER: VSI Fortran V8.3-104956-50P85
> This is interesting because if it wasn't on VMS Fortran in 1984 then someone added it later. We found it in code which was running on Itanium VMS but dated from the 1980s or before.

The one that I know, is that VAX Fortran didn't get past Fortran 77,
but Alpha and Itanium did. I don't know if that helps, though.

On 4/2/22 5:59 PM, gah4 wrote:
> On Saturday, April 2, 2022 at 9:11:41 AM UTC-7, john.c...@simconglobal.com wrote:
>> @gah4
>>> It is not in VAX Fortran of 1984. Which VMS versions have it?
>
>> We found this on Itanium, listing gives: COMPILER: VSI Fortran V8.3-104956-50P85
>> This is interesting because if it wasn't on VMS Fortran in 1984 then someone added it later. We found it in code which was running on Itanium VMS but dated from the 1980s or before.
>
> The one that I know, is that VAX Fortran didn't get past Fortran 77,
> but Alpha and Itanium did. I don't know if that helps, though.

I have always been perplexed about that era of computing. The VAX
hardware supported 4-byte, two different 8-byte, and 16-byte floating
point arithmetic. The 4- and 8-byte formats had hardware support
(depending on the VAX model I think), the 16-byte was mixed hardware and
software. That was an ideal situation for the way f90 could declare and
support all those different kinds. Yet, for some reason, the VAX never
supported an f90 compiler.

The Alpha and Itanium compilers supported those different floating point
formats to various extents, but I think they just did it by converting
the values to ieee format, they did not try to emulate the actual VAX
arithmetic.

$.02 -Ron Shepard

In article <QJj2K.526147$LN2.439229@fx13.iad>, Ron Shepard
<nospam@nowhere.org> writes:

> >>> It is not in VAX Fortran of 1984. Which VMS versions have it?
> >
> >> We found this on Itanium, listing gives: COMPILER: VSI Fortran V8.3-104956-50P85
> >> This is interesting because if it wasn't on VMS Fortran in 1984 then someone added it later. We found it in code which was running on Itanium VMS but dated from the 1980s or before.
> >
> > The one that I know, is that VAX Fortran didn't get past Fortran 77,
> > but Alpha and Itanium did. I don't know if that helps, though.
>
> I have always been perplexed about that era of computing. The VAX
> hardware supported 4-byte, two different 8-byte, and 16-byte floating
> point arithmetic. The 4- and 8-byte formats had hardware support
> (depending on the VAX model I think), the 16-byte was mixed hardware and
> software. That was an ideal situation for the way f90 could declare and
> support all those different kinds. Yet, for some reason, the VAX never
> supported an f90 compiler.

By the time the standard came out, VAX was on the way out. I think
that it was a good decision to say that Fortran 90 would be Alpha-only,
especially since most Fortran users probably wanted a fast machine, and
early Alphas were both faster and cheaper than comparable VAX models.

On 4/3/2022 12:14 PM, Ron Shepard wrote:
> The Alpha and Itanium compilers supported those different floating point
> formats to various extents, but I think they just did it by converting
> the values to ieee format, they did not try to emulate the actual VAX
> arithmetic.

I'm not sure about Itanium (tried to forget that), but Alpha had native
support for VAX single and double floating point formats and their
semantics. I have a faint recollection of there being something about
VAX D being treated internally as 53-bit mantissa instead of 56 bit, but
I could be misremembering.

On Alpha VMS, you could specify at compile time whether you wanted VAX
F/D, VAX F/G or IEEE S/T. Alpha supported IEEE quad format as "X float"
and software was used to convert VAX "H float" to X. Fortran I/O
supported conversion on read and write of all of these formats to and
from what the source was compiled with, as well as IBM/360 and CRAY
formats. (I wrote the run-time support for this.)

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

On 4/2/2022 12:11 PM, John Collins wrote:
> @gah4
>> It is not in VAX Fortran of 1984. Which VMS versions have it?
>
> We found this on Itanium, listing gives: COMPILER: VSI Fortran V8.3-104956-50P85
> This is interesting because if it wasn't on VMS Fortran in 1984 then someone added it later. We found it in code which was running on Itanium VMS but dated from the 1980s or before.
>
> I like the syntax - standard DATA statement syntax forces a special case handler for a general expression and this doesn't. It is not a major issue - no-one will change the DATA statement syntax now, but I am curious.
>
> It is supported by DVF/CVF and ifort. Perhaps Steve Lionel can comment?
>

I do not recall ever seeing that DATA syntax before. I am fairly certain
that the VAX FORTRAN-77 compiler did not support it. The DEC F90
compiler, though, was based on a front-end (language parser) from
COMPASS, and a number of COMPASS compiler developers were hired into the
DEC Fortran team. Over the years we discovered all sorts of weird syntax
extensions that COMPASS had inserted. Some of these got removed when
they were found. Needless to say, this one is not documented.

I do note that ifort/ifx doesn't complain about it if you ask for
standards checking, which is a bug that I reported as issue 05437508.

It does not astonish me that VSI Fortran supports it as HP forked the
DEC Fortran 90 compiler in the early years after the acquisition of
Compaq by HP. I think Intel provided some bug fixes for a few years, but
not new features. The VSI folk have had to reimplement the post-F95
features (the compiler was mostly F95 by that time and even had some of
the TR15581 features, such as allocatable components in derived type.)

My advice echoes others - replace the statement with standard syntax.

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

On Wednesday, April 13, 2022 at 5:52:07 PM UTC+1, Steve Lionel wrote:
<snip>>
> My advice echoes others - replace the statement with standard syntax.
> --
Thank you. We have changed the syntax to standard.
We have automated the replacement because we found several of them and there might be more. Also we had previously automated moving DATA for variables in COMMON to BLOCK DATA and we didn't want to rewrite that code for this new, exciting syntax.

But:

The standard syntax for the DATA statement is archaic. It requires an unique meaning for the * operator and an odd use of /. Shows its age!
This syntax is far more in keeping with the principal of least astonishment. Is there any chance of adding it to the standard?

On 4/13/2022 2:04 PM, John Collins wrote:
> The standard syntax for the DATA statement is archaic. It requires an unique meaning for the * operator and an odd use of /. Shows its age!
> This syntax is far more in keeping with the principal of least astonishment. Is there any chance of adding it to the standard?

This is why the "modern Fortran" way is to do initialization on the
statement that declares the variable. DATA itself is archaic (though not
yet obsolescent), dating from the era of implicit type declarations.
Given that there is a newer way to do initialization; one that doesn't
require the compiler to stand on its head to make sense of overlapping
DATA statements, I see no motive for simply altering the syntax of DATA.

As for the use of * and /, these do show up in other places. * as a
repeat count appears in list-directed and NAMELIST I/O, and slash as a
delimiter is used for COMMON.

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

On Wednesday, April 13, 2022 at 9:23:44 AM UTC-7, Steve Lionel wrote:
> On 4/3/2022 12:14 PM, Ron Shepard wrote:
> > The Alpha and Itanium compilers supported those different floating point
> > formats to various extents, but I think they just did it by converting
> > the values to ieee format, they did not try to emulate the actual VAX
> > arithmetic.

> I'm not sure about Itanium (tried to forget that), but Alpha had native
> support for VAX single and double floating point formats and their
> semantics. I have a faint recollection of there being something about
> VAX D being treated internally as 53-bit mantissa instead of 56 bit, but
> I could be misremembering.
> On Alpha VMS, you could specify at compile time whether you wanted VAX
> F/D, VAX F/G or IEEE S/T. Alpha supported IEEE quad format as "X float"
> and software was used to convert VAX "H float" to X.

I once knew about this.

As well as I remember, the F/D/G/H load/store instructions convert
between VAX byte order and Alpha byte order, even if they don't do
anything else. I don't remember now the exact difference, once
you change the byte order, between VAX and IEEE. There might
be a different exponent bias. And yes, it seems familiar, that for
D Float it throws away the three bits.

On Wednesday, April 13, 2022 at 12:18:31 PM UTC-7, Steve Lionel wrote:

(snip)

> This is why the "modern Fortran" way is to do initialization on the
> statement that declares the variable. DATA itself is archaic (though not
> yet obsolescent), dating from the era of implicit type declarations.
> Given that there is a newer way to do initialization; one that doesn't
> require the compiler to stand on its head to make sense of overlapping
> DATA statements, I see no motive for simply altering the syntax of DATA.
The IBM and some DEC Fortran compilers, at least to Fortran 66 days,
have a different declaration/initialization form:

REAL X/1.2/, Y/2.4/, Z(3)/1.,2.,3./

unlike DATA where you can initialize more that one variable with a group:

DATA X, Y, Z/1.2, 2.4,1.,2,.3./

you can only initialize the preceding variable (or array).

I don't remember that this ever got into any standard, though.

On Thursday, April 14, 2022 at 1:32:52 AM UTC+1, gah4 wrote:
> On Wednesday, April 13, 2022 at 12:18:31 PM UTC-7, Steve Lionel wrote:
>
> (snip)
> > This is why the "modern Fortran" way is to do initialization on the
> > statement that declares the variable. DATA itself is archaic (though not
> > yet obsolescent), dating from the era of implicit type declarations.
> > Given that there is a newer way to do initialization; one that doesn't
> > require the compiler to stand on its head to make sense of overlapping
> > DATA statements, I see no motive for simply altering the syntax of DATA..

I have made a compiler 'stand on its head' to handle DATA statements, and I agree strongly that the existing syntax has problems. But I don't think that the DATA statement can be replaced by embedded data in declarations in all cases. The following is a fragment from the data construct in fpt which specifies the name labels for intrinsic function and subroutine arguments:

DATA itr_lab_arg(:,k_len)/k_string,0,0,0,0,0/
DATA itr_lab_arg(:,k_index)/k_string,k_substring,k_back,0,0,0/
DATA itr_lab_arg(:,k_char)/k_i,k_kind,0,0,0,0/
DATA itr_lab_arg(:,k_ichar)/k_c,k_kind,0,0,0,0/
DATA itr_lab_arg(:,k_llt)/k_string_a,k_string_b,0,0,0,0/
DATA itr_lab_arg(:,k_lle)/k_string_a,k_string_b,0,0,0,0/
DATA itr_lab_arg(:,k_lgt)/k_string_a,k_string_b,0,0,0,0/
DATA itr_lab_arg(:,k_lge)/k_string_a,k_string_b,0,0,0,0/
DATA itr_lab_arg(:,k_sizeof)/0,0,0,0,0,0/

0 means no pre-defined label name. There is a unique integer value corresponding to every name, with the parameter value k_name. k_name specifies that the name corresponds to the serial position of the argument. There is an entry for every standard intrinsic and every intrinsic in VMS, MPX and HP3000 ... Fortran. There are similar tables for the data type and kind of the intrinsic returns. These have to be maintained by hand - the standard changes. I do not see how this information could be embedded in the declaration of itr_lab_arg. But if it can, I would be very happy!