The program
program main
implicit none
character (len=100) :: text
integer :: i,j(1)
text = "2 4"
read (text,*) i,i
read (text,*) j(1),j(1)
print*,"i=",i
print*,"j=",j
end program main
gives output
i= 4
j= 4
with gfortran and Intel Fortran. Section 10.4 of Metcalf/Reid/Cohen (2018) says
"However, no element of the array may appear more than once in an input item."
The program
program main
implicit none
character (len=100) :: text
integer :: i,j(1)
text = "2 4"
read (text,*) i,i
read (text,*) j(1),j(1)
print*,"i=",i
print*,"j=",j
end program main
gives output
i= 4
j= 4
with gfortran and Intel Fortran. Section 10.4 of Metcalf/Reid/Cohen (2018) says
"However, no element of the array may appear more than once in an input item."
so I think
read (text,*) j(1),j(1)
is non-standard. What about reading a scalar twice, as in
read (text,*) i,i
The reason to read a variable more than once is to skip over data.
The program
program main
implicit none
character (len=100) :: text
integer :: i,j(1)
text = "2 4"
read (text,*) i,i
read (text,*) j(1),j(1)
print*,"i=",i
print*,"j=",j
end program main
gives output
i= 4
j= 4
with gfortran and Intel Fortran. Section 10.4 of Metcalf/Reid/Cohen (2018) says
"However, no element of the array may appear more than once in an input item."
so I think
read (text,*) j(1),j(1)
is non-standard. What about reading a scalar twice, as in
read (text,*) i,i
The reason to read a variable more than once is to skip over data.
The program
program main
implicit none
character (len=100) :: text
integer :: i,j(1)
text = "2 4"
read (text,*) i,i
read (text,*) j(1),j(1)
print*,"i=",i
print*,"j=",j
end program main
gives output
i= 4
j= 4
with gfortran and Intel Fortran. Section 10.4 of Metcalf/Reid/Cohen (2018) says
"However, no element of the array may appear more than once in an input item."
so I think
read (text,*) j(1),j(1)
is non-standard.
On Tuesday, March 29, 2022 at 10:48:12 PM UTC-7, Ron Shepard wrote:
On 3/29/22 8:19 PM, Beliavsky wrote:
(snip)
with gfortran and Intel Fortran. Section 10.4 of Metcalf/Reid/Cohen (2018) says
"However, no element of the array may appear more than once in an input item."
I was not aware of this restriction. I checked the standard, and the
restriction is there, so MRC is correct. The example given in the
standard is an array referenced with a vector subscript, not with
literal constants, but I do not see any exception for that latter case.
Yes, I also found the restriction.
I don't think that is the case. F2018:
R1216 input-item is variable
or io-implied-do
so j(1) and j(1) are two separate input items, and the code is fine.
On 3/29/22 8:19 PM, Beliavsky wrote:
with gfortran and Intel Fortran. Section 10.4 of Metcalf/Reid/Cohen (2018) says
"However, no element of the array may appear more than once in an input item."
I was not aware of this restriction. I checked the standard, and the restriction is there, so MRC is correct. The example given in the
standard is an array referenced with a vector subscript, not with
literal constants, but I do not see any exception for that latter case.
is non-standard. What about reading a scalar twice, as in
read (text,*) i,i
The reason to read a variable more than once is to skip over data.
I do not see a similar restriction on repeated scalar variables in the
i/o list. I certainly see this done in practice for the reason you give,
to skip over items in the file and to ignore their values.
Note that the restriction is on an item, not an item list.
To expand on what I wrote earlier, this means that
read (10,*) a(1), a(1)
is fine, but
read (10,*) a([1,1])
or
read (10,*) (a(i/2),i=1,10)
or
read (10,*) (a(i),a(i),i=1,10)
is not.
On Tuesday, March 29, 2022 at 10:48:12 PM UTC-7, Ron Shepard wrote:
On 3/29/22 8:19 PM, Beliavsky wrote:(snip)
with gfortran and Intel Fortran. Section 10.4 of Metcalf/Reid/Cohen (2018) says
"However, no element of the array may appear more than once in an input item."
I was not aware of this restriction. I checked the standard, and the restriction is there, so MRC is correct. The example given in theYes, I also found the restriction.
standard is an array referenced with a vector subscript, not with
literal constants, but I do not see any exception for that latter case.
Note that there are a number of different ways to use array element that
can complicate I/O. Note, for example, (though I haven't looked recently)
to do something like:
READ(1) N, (X(I), Y(I), I=1,N)
Input items can be used in later items in the I/O list. I believe there is
a restriction on things like:
READ(1) (X(I), I=1,X(3))
where an input item is otherwise used in the same implied-DO group.
Now you get to things like:
READ(1) I, X(I), J, X(J)
which we know is legal when the read-in I is different from the read-in J. The discussed restriction suggests that it isn't if I equals J, even
though it doesn't look so much harder to process.
gah4 <gah4@u.washington.edu> schrieb:
On Tuesday, March 29, 2022 at 10:48:12 PM UTC-7, Ron Shepard wrote:
On 3/29/22 8:19 PM, Beliavsky wrote:
(snip)
with gfortran and Intel Fortran. Section 10.4 of Metcalf/Reid/Cohen (2018) says
"However, no element of the array may appear more than once in an input item."
I was not aware of this restriction. I checked the standard, and the
restriction is there, so MRC is correct. The example given in the
standard is an array referenced with a vector subscript, not with
literal constants, but I do not see any exception for that latter case.
Yes, I also found the restriction.
Note that the restriction is on an item, not an item list.
To expand on what I wrote earlier, this means that
read (10,*) a(1), a(1)
is fine, but
read (10,*) a([1,1])
or
read (10,*) (a(i/2),i=1,10)
or
read (10,*) (a(i),a(i),i=1,10)
is not.
On Tuesday, March 29, 2022 at 6:19:46 PM UTC-7, Beliavsky wrote:[...]
Note, for example, recent discussion on the END= or ERR= exit, which can occur
during execution of a READ statement, such that all variables listed should be
considered undefined. It would be nice to believe that earlier variables are fine,
and only later (not yet read) undefined, but the standard doesn't say that.
The program
program main
implicit none
character (len=100) :: text
integer :: i,j(1)
text = "2 4"
read (text,*) i,i
read (text,*) j(1),j(1)
print*,"i=",i
print*,"j=",j
end program main
gives output
i= 4
j= 4
with gfortran and Intel Fortran. Section 10.4 of Metcalf/Reid/Cohen (2018) says
"However, no element of the array may appear more than once in an input item."
so I think
read (text,*) j(1),j(1)
is non-standard. What about reading a scalar twice, as in
read (text,*) i,i
The reason to read a variable more than once is to skip over data.
"However, no element of the array may appear more than once in an input item."
There must have been a reason for this restriction, and the fact that it doesn't apply to scalars."However, no element of the array may appear more than once in an input item."
On Friday, April 1, 2022 at 11:12:14 AM UTC-7, john.c...@simconglobal.com wrote:.
The compiler can recognize at compile time when the same scalar is used.There must have been a reason for this restriction, and the fact that it doesn't apply to scalars."However, no element of the array may appear more than once in an input item."
With variable subscripts, it is harder for the compiler.
Often, though, my feeling is that there doesn't need to be a reason for a restriction,
but a reason to remove one.
Restrictions are added when someone thinks that it might be harder
for compilers to figure out, but not actually know that.
My thoughts about PL/I is that they added features without worry about
the complications for compiler writers. Simple rules make it easier for users, but also allow interesting things.
With ENTRY in functions, Fortran EQUIVALENCEs all the return values..
PL/I does the appropriate conversion. That might mean lots of conversion routines that would never be called, but it makes more sense for users.
The only complication with array elements is the possibility of
them being assigned in a different order than expected.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 157 |
Nodes: | 16 (0 / 16) |
Uptime: | 17:26:31 |
Calls: | 3,193 |
Files: | 10,512 |
Messages: | 2,978,882 |