internal file and namelist
John Harper
Can an internal file be used for f2003 namelist I/O? The f95 standard
9.2.2.2 prohibits it. If there is a corresponding prohibition in the
f2003 standard I failed to find it. MR&C "Fortran 95/2003 Explained"
9.10 mentions the f95 rule but chapters 19 and 20 say nothing about
it having changed in f2003. G95 compiles and runs the test program
below unless one uses the -std=f95 option, but Sun and Intel f95 and
gfortran won't, not even if one uses their -f2003 or -std03 or
-std=f2003 options.
character line*80
namelist /stuff/ n
n = 666
write(line,nml=stuff)
print *,trim(line)
end
If internal namelist I/O is still forbidden in f2003, then g95 would
seem to be allowing it as an extension. If internal namelist is OK in
f2003 then it appears to be a feature not implemented yet by the other
three compilers. None of the four claims to implement all of f2003 yet.
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 6780 fax (+64)(4)463 5045
glen herrmannsfeldt
> Can an internal file be used for f2003 namelist I/O? The f95 standard
> 9.2.2.2 prohibits it. If there is a corresponding prohibition in the
> f2003 standard I failed to find it. MR&C "Fortran 95/2003 Explained"
> 9.10 mentions the f95 rule but chapters 19 and 20 say nothing about
> it having changed in f2003.
I tried to find it last week in response to a post here,
but didn't see it.
Section 9.3 requires "sequential access formatted
input/output statements." It seems to me that NAMELIST
does that.
-- glen
Richard Maine
> Can an internal file be used for f2003 namelist I/O?
Yes. At least I can't find the prohibition either. I think I vaguely
recall something about this, but the recollection is dim, as it wasn't a
very big issue. I don't recall active requests for the feature, but I
think it stood out as a pointless restriction, at least after
list-directed internal I/O was allowed (and there were lots of requests
for that).
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Gary Scott
> John Harper <har...@mcs.vuw.ac.nz> wrote:
>
>
>>Can an internal file be used for f2003 namelist I/O?
>
>
> Yes. At least I can't find the prohibition either. I think I vaguely
> recall something about this, but the recollection is dim, as it wasn't a
> very big issue. I don't recall active requests for the feature, but I
> think it stood out as a pointless restriction, at least after
> list-directed internal I/O was allowed (and there were lots of requests
> for that).
I once made a request for namelist, but I had in mind using it for a
simple parser. I didn't want to have to write the namelist markup out
to a file to get it processed (seemed inefficient since I had just read
in the command to be parsed from a disk file). I also wanted a few
additional error codes so that I could diagnose particular types of
parsing errors.
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
James Van Buskirk
> gfortran won't
> character line*80
> namelist /stuff/ n
> n = 666
> write(line,nml=stuff)
> print *,trim(line)
> end
C:\gcc_mingw64a\clf\nakelist>type nakelist.f90
character line*80
namelist /stuff/ n
n = 666
write(line,nml=stuff)
print *,trim(line)
end
C:\gcc_mingw64a\clf\nakelist>x86_64-pc-mingw32-gfortran
nakelist.f90 -onakelist
C:\gcc_mingw64a\clf\nakelist>nakelist
&STUFF
N= 666, /
C:\gcc_mingw64a\clf\nakelist>x86_64-pc-mingw32-gfortran -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
../gcc/configure --prefix=/var/tmp/rt --with-sysroot=/var/tmp/r
t --host=i686-pc-mingw32 --target=x86_64-pc-mingw32 -q --silent
Thread model: win32
gcc version 4.4.0 20080705 (experimental) (GCC)
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Richard Maine
> C:\gcc_mingw64a\clf\nakelist>type nakelist.f90
> character line*80
> namelist /stuff/ n
> n = 666
> write(line,nml=stuff)
> print *,trim(line)
> end
>
> C:\gcc_mingw64a\clf\nakelist>x86_64-pc-mingw32-gfortran
> nakelist.f90 -onakelist
>
> C:\gcc_mingw64a\clf\nakelist>nakelist
> &STUFF
> N= 666, /
That output showed up in the posting as being on two lines (at least in
my newsreader). I hope that was an artifact of the newsgroup posting. If
the compiler actually does something like put control characters (such
as cr and/or lf) in the internal file, then that would be a bug.
Also, the comma looks wrong to me. I don't think it is allowed. I
suppose I'd need to study more carefully to be 100% sure, but the comma
is a separator - not a terminator. That also looks like a bug, and one
less likely to be a posting artifact.
glen herrmannsfeldt
>> &STUFF
>> N= 666, /
> That output showed up in the posting as being on two lines (at least in
> my newsreader). I hope that was an artifact of the newsgroup posting. If
> the compiler actually does something like put control characters (such
> as cr and/or lf) in the internal file, then that would be a bug.
I wondered about that, too. It might be better to give
it an array of CHARACTERs to allow for multiple record
output, but the sample program doesn't do that.
> Also, the comma looks wrong to me. I don't think it is allowed. I
> suppose I'd need to study more carefully to be 100% sure, but the comma
> is a separator - not a terminator. That also looks like a bug, and one
> less likely to be a posting artifact.
It does look strange, but I don't know that it is wrong.
I don't see that it is invalid as NAMELIST input, either.
The OS/360 NAMELIST uses &END as a terminator instead of /,
and it is usual to put a comma after the last item and before
the &END terminator. That seems less obvious for /, though.
-- glen
Dick Hendrickson
" Reading and writing records shall be accomplished only by
sequential access formatted input/output statements that do not specify
namelist formatting."
in the bulleted list of internal I/O restrictions.
The F2003 version dropped the "that do not specify namelist formatting".
It's one of those hard to find things where a restriction is
removed.
Dick Hendrickson
Dick Hendrickson
> James Van Buskirk <not_...@comcast.net> wrote:
>
>> C:\gcc_mingw64a\clf\nakelist>type nakelist.f90
>> character line*80
>> namelist /stuff/ n
>> n = 666
>> write(line,nml=stuff)
>> print *,trim(line)
>> end
>>
>> C:\gcc_mingw64a\clf\nakelist>x86_64-pc-mingw32-gfortran
>> nakelist.f90 -onakelist
>>
>> C:\gcc_mingw64a\clf\nakelist>nakelist
>> &STUFF
>> N= 666, /
>
> That output showed up in the posting as being on two lines (at least in
> my newsreader). I hope that was an artifact of the newsgroup posting. If
> the compiler actually does something like put control characters (such
> as cr and/or lf) in the internal file, then that would be a bug.
>
> Also, the comma looks wrong to me. I don't think it is allowed. I
> suppose I'd need to study more carefully to be 100% sure, but the comma
> is a separator - not a terminator. That also looks like a bug, and one
> less likely to be a posting artifact.
>
The intro to namelist in 10.10 says
"The characters in one or more namelist records constitute a
sequence of name-value subsequences, each of which consists
of an object designator followed by an equals and followed by
one or more values and value separators."
I'd say that means you can have a value separator after the
last value in the list and the above output is OK. I didn't
see any special cases for the last name=value in the output.
Dick Hendrickson
Richard Maine
> Richard Maine wrote:
> > James Van Buskirk <not_...@comcast.net> wrote:
> >> &STUFF
> >> N= 666, /
> >
> > Also, the comma looks wrong to me. I don't think it is allowed. I
> > suppose I'd need to study more carefully to be 100% sure, but the comma
> > is a separator - not a terminator. That also looks like a bug, and one
> > less likely to be a postinfg artifact.
> >
>
> The intro to namelist in 10.10 says
> "The characters in one or more namelist records constitute a
> sequence of name-value subsequences, each of which consists
> of an object designator followed by an equals and followed by
> one or more values and value separators."
>
> I'd say that means you can have a value separator after the
> last value in the list and the above output is OK. I didn't
> see any special cases for the last name=value in the output.
Perhaps. I wish that stuff was written more precisely. To me, the
namelist stuff seems to have an odd combination of being a bit imprecise
in some ways, yet obtuse in other ways.
The whole of 10.10.1.5 in f2003 seems pointless. Why would anyone care
about detailed rules for when a blank was considered to be part of a
value separator. It was already specified where blanks could be; I can't
see that anything would be any different if that section was just
omitted.
In contrast, the bit your quoted above seems awfully vague. It doesn't
even say that the values have to be separated by value separators.
Apparently one could have just a sequence of values, as in 12345 being 5
values? (Obviously not, as that would be ambiguous in a way that
mattered). One can sort of guess the general idea, assisted by the
terminology, but it doesn't actually say that I can see.
By that interpretation then, since you are saying that the comma counts
as part of the name-value subsequence, then we can also have things like
x=3, , y=4
because 10.10.1 says that the input has "a sequence of zero or more
name-value subsequences separated by value separators". If a name-value
subsequence can itself end in a value separator, then I guess we can
have 2 separators in a row like this, one part of the subsequence, and
one separating two subsequences.
But then it seems ambiguous whether or not there is a null value between
those commas. Maybe it doesn't matter. If x is an array, then a null
value would be ok there, but I suppose it has about the same effect as
there not being a null value. If x is scalar, a null value isn't
allowed, but maybe that just resolves the ambiguity. Seems messy, but I
suppose it could be that way.
I suppose I can buy that this might all be ok. But I'm not sure. The
standard seems awfully sloppily written in this area. (I suppose I
should be careful, as I don't know who wrote that part. Not me, but one
can always claim that I share the blame by a sin of omission in that I
didn't fix it.)
Hmm. I wonder if a certain book is any better. :-) I haven't actually
checked.
Dick Hendrickson
> Dick Hendrickson <dick.hen...@att.net> wrote:
>
>> Richard Maine wrote:
>>> James Van Buskirk <not_...@comcast.net> wrote:
>
>>>> &STUFF
>>>> N= 666, /
>>> Also, the comma looks wrong to me. I don't think it is allowed. I
>>> suppose I'd need to study more carefully to be 100% sure, but the comma
>>> is a separator - not a terminator. That also looks like a bug, and one
>>> less likely to be a postinfg artifact.
>>>
>> The intro to namelist in 10.10 says
>> "The characters in one or more namelist records constitute a
>> sequence of name-value subsequences, each of which consists
>> of an object designator followed by an equals and followed by
>> one or more values and value separators."
>>
>> I'd say that means you can have a value separator after the
>> last value in the list and the above output is OK. I didn't
>> see any special cases for the last name=value in the output.
>
> Perhaps. I wish that stuff was written more precisely. To me, the
> namelist stuff seems to have an odd combination of being a bit imprecise
> in some ways, yet obtuse in other ways.
Yes. :(
>
> The whole of 10.10.1.5 in f2003 seems pointless. Why would anyone care
> about detailed rules for when a blank was considered to be part of a
> value separator. It was already specified where blanks could be; I can't
> see that anything would be any different if that section was just
> omitted.
I disagree. It lists places where blanks can appear and NOT be
part of a value separator. Possible, it's a note level discussion,
but i don't think it's said anywhere else.
>
> In contrast, the bit your quoted above seems awfully vague. It doesn't
> even say that the values have to be separated by value separators.
> Apparently one could have just a sequence of values, as in 12345 being 5
> values? (Obviously not, as that would be ambiguous in a way that
> mattered). One can sort of guess the general idea, assisted by the
> terminology, but it doesn't actually say that I can see.
Yes, it's sure vague. I think it's easily deducible from the
definitions of list and sequence and that stuff, at least for
some definitions of "vague", "easily", and "deducible".
>
> By that interpretation then, since you are saying that the comma counts
> as part of the name-value subsequence, then we can also have things like
>
> x=3, , y=4
>
> because 10.10.1 says that the input has "a sequence of zero or more
> name-value subsequences separated by value separators". If a name-value
> subsequence can itself end in a value separator, then I guess we can
> have 2 separators in a row like this, one part of the subsequence, and
> one separating two subsequences.
I think that's legal, provided x is an array with dimension at
least 2. Only the first element is changed, there is an explicit
null value and then as many implicit null vales as needed to
not change anything else in x.
>
> But then it seems ambiguous whether or not there is a null value between
> those commas. Maybe it doesn't matter. If x is an array, then a null
> value would be ok there, but I suppose it has about the same effect as
> there not being a null value. If x is scalar, a null value isn't
> allowed, but maybe that just resolves the ambiguity. Seems messy, but I
> suppose it could be that way.
I think that's the way it is, including the "messy" observation.
>
> I suppose I can buy that this might all be ok. But I'm not sure. The
> standard seems awfully sloppily written in this area. (I suppose I
> should be careful, as I don't know who wrote that part. Not me, but one
> can always claim that I share the blame by a sin of omission in that I
> didn't fix it.)
Not me, either. I think it's OK in the sense that vendors seem
to understand it and do the right thing. There have been few,
if any, user/vendor interpretation requests about namelist.
>
> Hmm. I wonder if a certain book is any better. :-) I haven't actually
> checked.
>
I think we triggered two or three interpretation requests
while trying to write the chapter 10 stuff. That doesn't mean
it's any better.
Dick Hendrickson
Richard Maine
> Richard Maine wrote:
> > The whole of 10.10.1.5 in f2003 seems pointless. Why would anyone care
> > about detailed rules for when a blank was considered to be part of a
> > value separator. It was already specified where blanks could be; I can't
> > see that anything would be any different if that section was just
> > omitted.
> I disagree. It lists places where blanks can appear and NOT be
> part of a value separator. Possible, it's a note level discussion,
> but i don't think it's said anywhere else.
Looks to me like every single item there is said elsewhere. I just went
down the list and checked. And they would pretty much need to be. After
all, this section doesn't actually say that blanks are allowed in those
areas. It just says that if there are any blanks there, they aren't part
of a value separator. That's still true, perhaps doubly so, if blanks
aren't allowed there at all. (I'm reminded of the stages in the draft
when we had detailed syntax and semantics for some statements, but
forgot to actually include those statements as ones allowed anywhere in
a program; to my knowledge those all got fixed before release.)
As far as I can tell, the only non-redundant bit of the entire subclause
is to make pointless distinctions such as that in cases like
n= ,
where the blanks are allowed either as part of the separator or as
optional blanks following the "=", that they count as part of the
separator (if I got the double negative construct right) instead of as
being optional blanks after the "=". Why anyone would care I can't tell.
Now that I look at it again, the section also looks wrong. If it was
supposed to be a note-level listing of the places that blanks can be, it
seem sto have omitted namelist comments. So according to that section, I
think that blanks in namelist comments are all considered to be part of
some value separator, not that this seem consistent for the syntax of a
value separator (which can have blanks, but they are supposed to be
contiguous).
James Giles
some BNF rules? They don't have to be numbered (since
they don't apply to program source). Being explicit instead
of vague would seem an advantage. Assuming that at least
some implementors have been just as confused as the rest
of us, such a formal spec might even provide a basis for
fixing some non-conforming implementations.
--
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
"Simplicity is prerequisite for reliability" -- E. W. Dijkstra