NAMELIST questions raised while testing it's use in parsing command line arguments
John
I have been experimenting with combining the F2003 feature for reading
command line parameters with the F2003 ability to read
NAMELIST from an interal file, and find the result is a way to read
options from a command line that is very easy to code and extremely
flexible
It is easy to input small arrays or
values of any type in any order and provide an interactive or file-
based
alternative with no additional coding.
As an aside, I find the gfortran extension for interactive input that
allows a ? to
display the namelist elements, and to not end the read on a syntax
error
very complimentary to this.
But there seem to be some dusty corners in NAMELIST, or it is not
fully implemented
in a lot of compilers. The good news is the differences I found so far
don't effect the most
common things I would enter on command lines. But since all the
compilers
I have tried all support reading NAMELIST from an INTERNAL file, The
differences
in NAMELIST input and output seem to imply they are all supporting
F2003 NAMELIST, yet
I found many differences; and am finding it hard to confirm whether
some of this is just allowable
differences or bugs, even after several hours with the standard and
major vendor's web sites.
A sample test program and test script (Bourne) and the output from
running the script
using g95 and gfortran are at:
http://home.comcast.net/~urbanjost/CLONE/KRACKEN/namelist/index.html
as cmdline_tiny.f90 and testtiny.sh
You can run the program with arguments like:
./cmdline_tiny I=10 J=20 S=3.45 T=400.4e3 QUIT=.TRUE.
./cmdline_tiny L=1111,2222,3333 L=,,4444 'L(2)=5555' ! array
syntax tests
./cmdline_tiny "I=1111 j=22222 C='Eggs' quit=t SMITH%P_HEIGHT=5.10"
For example, here is the output from gfortran and g95 using the same
input:
GFORTRAN OUTPUT:
================================================================================
command line as received by program:
I=1111 j=22222 C='Eggs' quit=t SMITH%P_HEIGHT=5.10
================================================================================
resulting namelist group values
&CMD
I= 1111,
J= 22222,
C=Eggs ,
K= 3,
L= 10, 20, 30,
SMITH%P_AGE= 20,
SMITH%P_NAME=john smith ,
SMITH%P_HEIGHT= 5.0999999 ,
QUIT=T,
S= 1,
T= 2,
R= 3, /
================================================================================
G95 OUTPUT:
================================================================================
command line as received by program:
I=1111 j=22222 C='Eggs' quit=t SMITH%P_HEIGHT=5.10
================================================================================
resulting namelist group values
&CMD I = 1111, J = 22222, C = 'Eggs ', K = 3, L = 10, 20,
30, SMITH = 20, 'john smith ', 5.1, QUIT = T,
S = 1, T = 2, R = 3,
/
================================================================================
Some of the questions coming out of this are:
BLANKS IN COLUMN 1:
Should & be in column 1, as it is in output from gfortran?
Documentation on IBM site
indicates column 1 should be blank; gfortran and g95 leave it blank on
output except
gfortran puts & in column 1; if column 1 is supposed to be blank, test
that continued
strings do not include it. I could not find a clear statement in the
standard. It seemed
to imply NAMELIST and list-directed output would leave column 1 blank,
but did not seem
to restrict it on input for NAMELIST input.
-------------------------------------------
ALL VALUES SPECIFIED BUT DUPLICATES FOLLOW:
Should duplicates be used if all values in the namelist are
specified first? The standard
states if all values are specified a READ completes. So if a list
just had I in it
& CMD I=10 I=20 / ! I would be 10
But if the NAMELIST had members I and J
& CMD I=10 I=20 / ! I would be 20 (because J not specified)
-------------------------------------------
COMMENTS IN INTERNAL READS:
gfortran seems to allow a comment unless that is all that is in the
input
-------------------------------------------
ARE PRECEDING CORRECT VALUES DEFINED IF AN ERROR OCCURS ON INPUT?
F2003 standard seems to be contradictory. Since the program does
not seem to be able to
know what variable name it failed on, it seems there is no sense in
trusting any of it
anyway; but gfortran corrupts C when it is specified incorrectly,
g95 leaves it alone;
and gfortran seems to take a string without delimiters.
-------------------------------------------
ARE OUTPUT NAMES ALWAYS IN UPPERCASE?
Actually, I guess what I want is a less flexible way to output a
NAMELIST sothe output can be parsed
easily by other languages.
If I wanted to use NAMELIST output as a relatively easily parsed
syntax from other language
(that is, if I wanted to make a perl(1) or python(1) or ruby(1)
interface that could read
NAMELIST output, having to deal with the differences that are
apparently allowed (see g95
and gfortran output above) would make that difficult enough that
people would be tempted
to make their own formats.
-------------------------------------------
DEFAULT DELIMITERS
g95 seems to default to putting apostrophes around strings (which is
nice, as they can be
used easily for input) but gfortran does not; the standard seems to
imply DELIM= is required
to get quotes or apostrophes; no one I tried takes DELIM= on a WRITE
or on an OPEN of *; they
will take it on unit 6. But what should the default be? From what I
read of the standard,
no quotes seems to be the right answer (even though the quotes make
more sense to me).
VERY DIFFERENT DEFAULT OUTPUT
gfortran starts a new line with a new value, and shows members of user-
defined types by name.
g95 shows in a compact manner. As long as everyone can read it in I
guess that is fine, but
that's quite a difference for a "standard".
UNRELATED
Does not have anything to do with use in command line cracking, but ?
when reading from stdin
in gfortran displays list of members of the namelist, and a typo
produces an intelligible message
instead of going to ERR= so you can correct it interactively; and
IOMESG= is supported. Nice for
interactive reads; which you might want to use as an option to go with
command line parsing. So
./cmdline <<EOF
&CMD
I=10
J=20
\
EOF
./cmdline I=10 J=20
./cmdline
&CMD
?
I=19
/
would all work if you just did a READ if no parameters are specified
on command line, for example
Clive Page
<95828284-bfef-4c90...@o21g2000vbl.googlegroups.com>,
John <urba...@comcast.net> writes
>
>I have been experimenting with combining the F2003 feature for reading
>command line parameters with the F2003 ability to read
>NAMELIST from an interal file, and find the result is a way to read
>options from a command line that is very easy to code and extremely
>flexible
>It is easy to input small arrays or
>values of any type in any order and provide an interactive or file-
>based
>alternative with no additional coding.
Thanks for doing all those experiments and posting the results. I first
came across NAMELIST in the 1960s I think when using an IBM machine, but
decided it was too limited to be much use. I was surprised, therefore,
when it appeared, more or less in the 1960s version I remembered, in the
Fortran90 Standard. I think what you have uncovered is the result of a
combination of (a) a not very watertight definition in the Standard, and
(b) some half-hearted efforts to implement by the current generation of
compiler-writers.
I'm still in two minds about this: I have used it a few times recently
to parse parameter files, and as you show, it is potentially a good way
of parsing command lines. But the rather archaic syntax rules (why the
need for the ampersands, I wonder) and the poor implementations make it
perhaps just short of being useful except in very limited ways.
It's a pity that nobody got involved in this a bit earlier - we might
have been able to fix the worst features and ambiguities of NAMELIST in
time for Fortran 2008, but it's too late now, I think.
--
Clive Page
Jerry DeLisle
> In message
> <95828284-bfef-4c90...@o21g2000vbl.googlegroups.com>,
> John <urba...@comcast.net> writes
>>
>> I have been experimenting with combining the F2003 feature for reading
>> command line parameters with the F2003 ability to read
>> NAMELIST from an interal file, and find the result is a way to read
>> options from a command line that is very easy to code and extremely
>> flexible
>> It is easy to input small arrays or
>> values of any type in any order and provide an interactive or file-
>> based
>> alternative with no additional coding.
>
> Thanks for doing all those experiments and posting the results. I first
> came across NAMELIST in the 1960s I think when using an IBM machine, but
> decided it was too limited to be much use. I was surprised, therefore,
> when it appeared, more or less in the 1960s version I remembered, in the
> Fortran90 Standard. I think what you have uncovered is the result of a
> combination of (a) a not very watertight definition in the Standard, and
> (b) some half-hearted efforts to implement by the current generation of
> compiler-writers.
>
while implementing NAMELIST features. It certainly is not a half-hearted effort.
Some of my soul is in there. :)
> I'm still in two minds about this: I have used it a few times recently
> to parse parameter files, and as you show, it is potentially a good way
> of parsing command lines. But the rather archaic syntax rules (why the
> need for the ampersands, I wonder) and the poor implementations make it
> perhaps just short of being useful except in very limited ways.
>
> It's a pity that nobody got involved in this a bit earlier - we might
> have been able to fix the worst features and ambiguities of NAMELIST in
> time for Fortran 2008, but it's too late now, I think.
>
There are many "processor dependent" aspects to this. Most of the archaic rules
are for compatibility with legacy code, which is very important. Think of it as
art. :)
steve
> ARE OUTPUT NAMES ALWAYS IN UPPERCASE?
>
> Actually, I guess what I want is a less flexible way to output a
> NAMELIST sothe output can be parsed
> easily by other languages.
>
Yes. See Section
10.10.2 Namelist output
The form of the output produced is the same as that required
for input, except for the forms of real, character, and logical
values. The name in the output is in upper case.
--
steve
Clive Page
<jvde...@verizon.net> writes
>Speaking for gfortran, We have paid close attention to the standard
>while implementing NAMELIST features. It certainly is not a
>half-hearted effort. Some of my soul is in there. :)
Sorry, I didn't mean that criticism of you or of gfortran. I have great
admiration for all those who have worked on the gfortran compiler. From
the experiments reported here, it appears to be ahead of other compilers
in this respect.
But as John noted, only some of the current crop of compilers support
NAMELIST from internal files, even though they often claim to have added
many of the simpler of features F2003.
--
Clive Page
John
> In message <Lfwmm.293$Jd...@nwrddc02.gnilink.net>, Jerry DeLisle
I have flirted with NAMELIST in the past; but the portability/
longevity requirements
of the codes I typically work with made using a non-standard feature
unacceptable.
But NAMELIST has always had some tempting features (or it would not
have survived outside
the standard so many years, as you note!). The idea that programs can
use the same annotatable language-standardized syntax for command
line parameters, interactive input, batch reads of multiple input
sets, state
checkpoint/restore, ... is very appealing. Short of a built-in
interpreter, I can't think of
anything more appealing for line-mode I/O, but the odd input syntax
(more suitable for batch files)
and lack of portability caused me to develop my own library of tools
to do these tasks in the past.
But a mix of NAMELIST and internal files and the new environmental
interface routines almost gets
me there. A simple way to just print particular parts of a group
(maybe "WRITE(*,NML=name)ITEM_NAME)" ?)
and a simple method to ask for a prompt when interactive ( maybe
ITEM_NAME?, where the "?" on the end could
display an assigned prompt) and so on and I'd be there (see the busy
little test program "all.f90" at
http://home.comcast.net/~urbanjost/CLONE/KRACKEN/namelist/index.html
).
The gfortran implementation of NAMELIST, including the support of very
nice interactive extensions (and human-readable messages
returned in IOMSG=message!!) makes it's NAMELIST support best-of-class
out of what I've tested so far -- I was using it for most
of the testing specifically because it had the most complete support
of the features I was trying. I also didn't intend to
reflect negatively on gfortran's NAMELIST .
NAMELIST or something like it has so much promise, it's frustrating to
be so close and yet so far. Oddities such as String output that by
default can't be
used as input (I could just use a write statement if I wanted to do
that ); an overly flexible output format that makes it
hard to use for passing data to interpreted languages (although there
are modules out there for NAMELIST and perl(1) and python(1)),
which it could be a natural for, ..., the difficulty in passing a
NAMELIST group (it would be very nice if it acted like a user-defined
type for passing to procedures). .. and still I'm findig uses for it
now that it is "standardized" (well, almost:>).
The fact that many major Fortran program's I/O requirements are large;
and that NAMELIST is more a feature to be used by small
"utility" programs and simple interactive programs that many systems
have relegated to C might be another reason NAMELIST is often
overlooked.
Thanks;
Urban
Bil Kleb
>
> I have flirted with NAMELIST in the past; but the portability/
> longevity requirements of the codes I typically work with made
> using a non-standard feature unacceptable.
We used to avoid NAMELISTs for the same reason (non-standard), but
as of Fortran 90, they are standard.
Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov
glen herrmannsfeldt
(snip)
< I have flirted with NAMELIST in the past; but the portability/
< longevity requirements of the codes I typically work with made
< using a non-standard feature unacceptable.
< But NAMELIST has always had some tempting features (or it
< would not have survived outside the standard so many years,
< as you note!). The idea that programs can use the same annotatable
< language-standardized syntax for command line parameters,
< interactive input, batch reads of multiple input sets, state
< checkpoint/restore, ... is very appealing. Short of a built-in
< interpreter, I can't think of
< anything more appealing for line-mode I/O, but the odd input syntax
< (more suitable for batch files)
< and lack of portability caused me to develop my own library of tools
< to do these tasks in the past.
Yes. I do like the PL/I DATA directed I/O better than NAMELIST,
though they aren't all that different. No NAMELIST name is used,
it runs in stream mode, and terminates with just a semicolon.
Both work for debugging. PL/I has an interesting feature that
Fortran never got, in that the I/O list is optional. If omitted,
all names in scope are included, for either input or output.
< NAMELIST or something like it has so much promise, it's frustrating to
< be so close and yet so far. Oddities such as String output that by
< default can't be used as input (I could just use a write statement
< if I wanted to do that ); an overly flexible output format that makes it
< hard to use for passing data to interpreted languages (although there
< are modules out there for NAMELIST and perl(1) and python(1)),
< which it could be a natural for, ..., the difficulty in passing a
< NAMELIST group (it would be very nice if it acted like a user-defined
< type for passing to procedures). .. and still I'm findig uses for it
< now that it is "standardized" (well, almost:>).
Also, PL/I has always allowed internal I/O for all stream I/O forms.
-- glen
Clive Page
<8c3e517e-f2e3-45af...@y10g2000prf.googlegroups.com>,
steve <kar...@comcast.net> writes
> 10.10.2 Namelist output
>
> The form of the output produced is the same as that required
> for input, except for the forms of real, character, and logical
> values.
Nobody else seems to have commented on this: There are just 5 intrinsic
data types in Fortran90 and later - I guess that Complex follows the
rules for Real so that its output may not always be compatible with
input. So that means just one of the five types (Integer) can be used
with confidence in NAMELIST, if you want to do output and re-input.
That would seem to have been a relatively easy thing to get fixed in the
standard (but too late for Fortran 2008 now I guess).
--
Clive Page
robin
news:h7h65m$917$1...@naig.caltech.edu...
> John <urba...@comcast.net> wrote:
> (snip)
>
> < I have flirted with NAMELIST in the past; but the portability/
> < longevity requirements of the codes I typically work with made
> < using a non-standard feature unacceptable.
> < But NAMELIST has always had some tempting features (or it
> < would not have survived outside the standard so many years,
> < as you note!). The idea that programs can use the same annotatable
> < language-standardized syntax for command line parameters,
> < interactive input, batch reads of multiple input sets, state
> < checkpoint/restore, ... is very appealing. Short of a built-in
> < interpreter, I can't think of
> < anything more appealing for line-mode I/O, but the odd input syntax
> < (more suitable for batch files)
> < and lack of portability caused me to develop my own library of tools
> < to do these tasks in the past.
>
> Yes. I do like the PL/I DATA directed I/O better than NAMELIST,
> though they aren't all that different. No NAMELIST name is used,
> it runs in stream mode, and terminates with just a semicolon.
> Both work for debugging. PL/I has an interesting feature that
> Fortran never got, in that the I/O list is optional. If omitted,
> all names in scope are included, for either input or output.
For input in PL/I, when a list of names is provided for input, one or more
of those names may be omitted from the data, in which case
only those names that are provided with values are changed;
the remainder are untouched.
I especially like the form
put(x);
which delivers the name of the variable as well as its value.
It's so simple to slip it in when debugging.
This form is available for normal I/O as well as for debuggung.
> < NAMELIST or something like it has so much promise, it's frustrating to
> < be so close and yet so far. Oddities such as String output that by
> < default can't be used as input (I could just use a write statement
> < if I wanted to do that ); an overly flexible output format that makes it
> < hard to use for passing data to interpreted languages (although there
> < are modules out there for NAMELIST and perl(1) and python(1)),
> < which it could be a natural for, ..., the difficulty in passing a
> < NAMELIST group (it would be very nice if it acted like a user-defined
> < type for passing to procedures). .. and still I'm findig uses for it
> < now that it is "standardized" (well, almost:>).
>
> Also, PL/I has always allowed internal I/O for all stream I/O forms.
including in recursive situations (which are prohibited in Fortran).
The names and their values can come from anywhere -- including from
the command line, files, and of course the standard input.
Dick Hendrickson
This has been changed in F2008 (although not all compilers have
been updated yet) to:
"10.11.4.1 Form of namelist output
The form of the output produced by intrinsic namelist output
shall be suitable for input, except for character
output. ...
The form of the output produced by defined output (9.6.4.7)
is determined by the defined output procedure; this form need
not be compatible with namelist input."
Also, I'm not really sure what "your" quoted passage means. The
same words are in F95, but a couple of paragraphs later it defines
logical output to be T or F and real output to be the same as that
produced by an E or F descriptor; which sounds like it would be
readable.
I think the differences in character are whether or not the output
is delimited and how end of line is treated in long strings.
There's no hope for user defined derived type namelist output,
not for list-directed either.
Dick Hendrickson
James J. Weinkam
>
> I especially like the form
> put(x);
> which delivers the name of the variable as well as its value.
> It's so simple to slip it in when debugging.
>
DATA directed.
glen herrmannsfeldt
< In every version of PL/I I ever used put (x) implied LIST
< directed output, not DATA directed.
I didn't remember that the directive was optional, but I
agree DATA is not likely the default.
Also, the PL/I EDIT directed output has some interesting difference
to Fortran FORMAT directed output. Among others, it stops just
after the last list item has been used. Like C printf, it is a
stream mode (non-advancing in Fortran terms), so it is easy to
generate complicated lines built up from many such statements.
There isn't a form that allows interpreting a character string
as a format string, but otherwise the actual format description
is a little more powerful than in Fortran.
-- glen
Peter Flass
I was sure there was at least one PL/I compiler that had a nonstandard
builtin that would encode a character string as a format, but I can't
find the reference just now. At any rate, the combination of remote
format statements and expressions in the format specification allows
just about anything.
John W Kennedy
And at the cost of a lot less CPU time, since the bloody thing doesn't
have to be parsed.
glen herrmannsfeldt
(snip, I wrote)
<> Also, the PL/I EDIT directed output has some interesting difference
<> to Fortran FORMAT directed output. Among others, it stops just
<> after the last list item has been used. Like C printf, it is a
<> stream mode (non-advancing in Fortran terms), so it is easy to
<> generate complicated lines built up from many such statements.
<> There isn't a form that allows interpreting a character string
<> as a format string, but otherwise the actual format description
<> is a little more powerful than in Fortran.
< I was sure there was at least one PL/I compiler that had a nonstandard
< builtin that would encode a character string as a format, but I can't
< find the reference just now. At any rate, the combination of remote
< format statements and expressions in the format specification allows
< just about anything.
I suppose just about anything except reading in a format string.
You can do many strange things with the R (remote) format
descriptor and LABEL variables.
Also, the differences are enough to wonder about those who thought
PL/I could replace Fortran (Fortran V, or so).
-- glen
Clive Page
<dick.hen...@att.net> writes
>This has been changed in F2008 (although not all compilers have
>been updated yet) to:
Thanks, that's good to know. I confess to having been too lazy to check
on the F2008 situation, despite having downloaded the draft recently.
>Also, I'm not really sure what "your" quoted passage means. The
>same words are in F95, but a couple of paragraphs later it defines
>logical output to be T or F and real output to be the same as that
>produced by an E or F descriptor; which sounds like it would be
>readable.
Yes, Logical seems simple enough that it ought to be no trouble.
With Real/Complex: my guess is that the output of special strings like
NaN or +Inf might be incompatible with input. Maybe that's what's been
fixed in F2008?
>There's no hope for user defined derived type namelist output,
>not for list-directed either.
Well I tested it using g95 and gfortran and it worked, for a fairly
simple derived type, though I didn't check output using one compiler and
input using the other, which might have been interesting. But there are
so many complications with derived type I/O, that I doubt if it's
something one could rely upon, I agree.
--
Clive Page
robin
> I suppose just about anything except reading in a format string.
> You can do many strange things with the R (remote) format
> descriptor and LABEL variables.
>
> Also, the differences are enough to wonder about those who thought
> PL/I could replace Fortran (Fortran V, or so).
The differences are not so great, and in any case FORTRAN's output
can be exactly duplicated in PL/I.
robin
news:h7kd6d$j7s$1...@news.eternal-september.org...
> glen herrmannsfeldt wrote:
>> Also, the PL/I EDIT directed output has some interesting difference
>> to Fortran FORMAT directed output. Among others, it stops just
>> after the last list item has been used. Like C printf, it is a
>> stream mode (non-advancing in Fortran terms), so it is easy to
>> generate complicated lines built up from many such statements.
>>
>> There isn't a form that allows interpreting a character string
>> as a format string, but otherwise the actual format description
>> is a little more powerful than in Fortran.
>
> I was sure there was at least one PL/I compiler that had a nonstandard
> builtin that would encode a character string as a format, but I can't find
> the reference just now. At any rate, the combination of remote format
> statements and expressions in the format specification allows just about
> anything.
The fact that PL/I accepts expressions for the repeat factor, the width,
and the number of decimal places, etc, meant that it is unnecessary to
generate special formats a la Fortran.
Nevertheless, the EDIT built-in function permits formats to be built up
at run time, if required.
robin
> In comp.lang.fortran James J. Weinkam <j...@cs.sfu.ca> wrote:
>
> < In every version of PL/I I ever used put (x) implied LIST
> < directed output, not DATA directed.
>
> I didn't remember that the directive was optional, but I
> agree DATA is not likely the default.
>
> Also, the PL/I EDIT directed output has some interesting difference
> to Fortran FORMAT directed output. Among others, it stops just
> after the last list item has been used.
That was to avoid the bug in FORTRAN whereby text
embedded at the beginning of the format statement was printed again
after the final data item (repeating what was already at the beginning
of the output).
That deficiency was corrected in Fortran 90, with the addition of the
colon ( : ) which causes termination of format processing.
> Like C printf, it is a
> stream mode (non-advancing in Fortran terms), so it is easy to
> generate complicated lines built up from many such statements.
>
> There isn't a form that allows interpreting a character string
> as a format string, but otherwise the actual format description
> is a little more powerful than in Fortran.
However, NAMELIST still has incompatible forms for input and output.
You would think that after 40 years it would have been fixed.
robin
news:4a9dc6d2$0$22528$607e...@cv.net...
It has to be parsed sometime, but I think that what you mean is
that it doesn't have to be parsed at run time. Of course, it must
be parsed, usually at compile time.
robin
news:Mydnm.43374$PH1.7282@edtnps82...
You're right, I should have written
put data (x);
I must have been dreaming. Thanks.
Dick Hendrickson
problem implementing defined I/O. The problem is that defined
output isn't necessarily readable by defined input. After all,
the defined output routine doesn't have to follow the namelist
rules, heck it doesn't even have to output anything.
Dick Hendrickson
Dick Hendrickson
> "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
> news:h7jq06$41s$1...@naig.caltech.edu...
>>[snip]
>> There isn't a form that allows interpreting a character string
>> as a format string, but otherwise the actual format description
>> is a little more powerful than in Fortran.
>
> However, NAMELIST still has incompatible forms for input and output.
> You would think that after 40 years it would have been fixed.
>
>
I think it has been. For characters you need to use one of
the delimited forms for the strings (I'm not sure about
strings that contain internal quotes and wrap over several
lines). For user defined namelist I/O you just have to
write the output and input routines to be aware of what each
other is doing--that's no different from normal I/O. I
think all of the non-character intrinsic types now produce
output that is inputable.
Also, namelist was only standardized in 1990, so it's only
been 13 or 18 years, not 40 ;).
Dick Hendrickson
glen herrmannsfeldt
(snip regarding compile time and run time implementation of FORMAT)
< It has to be parsed sometime, but I think that what you mean is
< that it doesn't have to be parsed at run time. Of course, it must
< be parsed, usually at compile time.
In the days of FORMAT statements, most that I knew stored it in
a compact internal representation after parsing the FORMAT
(and diagnosing any errors). Now, with the more popular character
constant in the WRITE statement, the obvious solution is to use the
run-time format parser, but it might be that most still treat them
as compile time format, and special case the CHARACTER variable.
-- glen
Ron Shepard
"robin" <rob...@bigpond.com> wrote:
> That was to avoid the bug in FORTRAN whereby text
> embedded at the beginning of the format statement was printed again
> after the final data item (repeating what was already at the beginning
> of the output).
> That deficiency was corrected in Fortran 90, with the addition of the
> colon ( : ) which causes termination of format processing.
I'm pretty sure that the colon format was introduced in f77, not
f90. Although my memory might be off, I remember using it freely in
the 80's, and I don't remember having any problems with portability.
Of course, I used NAMELIST I/O in the 80's too, and I seldom had
portability problems with it either. The only ones I remember were
starting in about 1989 many of the compilers switched to the
*proposed* f90 form of the read statement (i.e. needing nml=xxx), so
I had to toggle back and forth. The other one involved character
variables, so I avoided that too. Then as f90 was adopted later in
the 90's, there were portability problems related to the input and
output data format (i.e. using / rather than &end to terminate).
None of these were serious enough for me to avoid using NAMELIST
input, it made too many things very much simpler.
$.02 -Ron Shepard
Richard Maine
> I'm pretty sure that the colon format was introduced in f77, not
> f90.
Yes.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Richard Maine
> Clive Page wrote:
> > In message <7g4p7uF...@mid.individual.net>, Dick Hendrickson
> > <dick.hen...@att.net> writes
> > >There's no hope for user defined derived type namelist output,
> > >not for list-directed either.
> >
> > Well I tested it using g95 and gfortran and it worked, for a fairly
> > simple derived type...
> I was a little imprecise when I said "no hope". There's no
> problem implementing defined I/O. The problem is that defined
> output isn't necessarily readable by defined input. After all,
> the defined output routine doesn't have to follow the namelist
> rules, heck it doesn't even have to output anything.
Yes. Clive obviously overlooked the "user-defined" qualifier of your
comment. That qualifier is indeed easy to overlook, but it was the whole
point.
To Clive: That's an f2003 feature, and one not widely implemented in
compilers. It is also an f2003 feature that I think has particularly
poor cost/benefit; apparently the compiler writers agree with me.
Clive Page
<nos...@see.signature> writes
>To Clive: That's an f2003 feature, and one not widely implemented in
>compilers. It is also an f2003 feature that I think has particularly
>poor cost/benefit; apparently the compiler writers agree with me.
Quite right - I mis-understood Dick's sentence as referring to a
user-defined data type.
As you say, not widely implemented. Is there even a single person who
has used it yet?
--
Clive Page
dpb
...
> As you say, not widely implemented. Is there even a single person who
> has used it yet?
Well, if it isn't implemented I suppose the answer to that question
would still be "no"... <VVBG>
--
Richard Maine
> In message <1j5ezup.1x1r36ovbr4lcN%nos...@see.signature>, Richard Maine
> <nos...@see.signature> writes
> >To Clive: That's an f2003 feature, and one not widely implemented in
> >compilers. It is also an f2003 feature that I think has particularly
> >poor cost/benefit; apparently the compiler writers agree with me.
>
> Quite right - I mis-understood Dick's sentence as referring to a
> user-defined data type.
Yeah. I suppose I see the potential confusion there, as it is indeed
also about user-defined data types. But "user-defined type" is (mostly)
redundant with "derived type" today. There is intrinsic I/O for
user-defined types, and that should be no particular problem. It is the
user-defined I/O part that has "no hope" of being specified by the
standard to be able to input its own output.
> As you say, not widely implemented. Is there even a single person who
> has used it yet?
Probably, but I couldn't name one. According to the table in the latest
issue of "FORTRAN forum", the IBM and Cray compilers support it, so it
seems a good guess that someone must have used it - probably at least
the compiler testing groups for those vendors.
I also happen to think the feature is incompletely integrated in the
standard. If one is going to have the feature at all, I'd think one
might as well integrate it a little better. In particular, I see no
reason why it should be restricted to derived types. There have been
multiple requests for special features that, as far as I can see, don't
actually need a separate feature, but could be addressed simply by
lifting the restriction that defined I/O apply only to derived types.
One wouldn't even have to add any extra material to the standard (and I
doubt it would be more complicated to implement than defined I/O of
derived types). It isn't as though user-defined things on intrinsic
types are an anathema - we already have such things as user-defined
operations on intrinsic types.
For those who wonder what kinds of feature requests would be addressed
by lifting that restriction, search the newsgroup for the multiple
requests for things like ways to control the details of list-directed
(or namelist, but list-directed is more common) output. People often ask
to be able to control how many significant digits are printed.
Occasionally you see things like requests to have, for example, the
value 1000000 output as 1,000,000. Defined output for reals and integers
could do those kinds of things without needing special-case features.
To me, that would be an excellent example of integration - recognizing
the common points that might be able to replace multiple special-case
features with a single more general one.
robin
> In comp.lang.fortran robin <rob...@bigpond.com> wrote:
> (snip regarding compile time and run time implementation of FORMAT)
>
> < It has to be parsed sometime, but I think that what you mean is
> < that it doesn't have to be parsed at run time. Of course, it must
> < be parsed, usually at compile time.
>
> In the days of FORMAT statements, most that I knew stored it in
> a compact internal representation after parsing the FORMAT
> (and diagnosing any errors). Now, with the more popular character
> constant in the WRITE statement, the obvious solution is to use the
> run-time format parser,
As it's a character CONSTANT, the obvious solution is to parse
at compile time ; it's no different from the case of a separate FORMAT
statement.
> but it might be that most still treat them
> as compile time format, and special case the CHARACTER variable.
RUN-time formats have been with FORTRAN compilers since
very early. They were parsed at run-time, while FORMAT statements
were generally parsed at compile time (though I think that there
were some that did all at run time).
robin
news:7g7ircF...@mid.individual.net...
> robin wrote:
>> "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
>> news:h7jq06$41s$1...@naig.caltech.edu...
>
>>>[snip]
>>> There isn't a form that allows interpreting a character string
>>> as a format string, but otherwise the actual format description
>>> is a little more powerful than in Fortran.
>>
>> However, NAMELIST still has incompatible forms for input and output.
>> You would think that after 40 years it would have been fixed.
> I think it has been.
No you don't. You just contradicted what you wrote yesterday (in this very
thread) :-
+From: "Dick Hendrickson" <dick.hen...@att.net>
+"Newsgroups: comp.lang.fortran
+Sent: Wednesday, 2 September 2009 12:26 AM
+Subject: Re: NAMELIST questions raised while testing it's use in parsing
command line arguments
+ "10.11.4.1 Form of namelist output
+ The form of the output produced by intrinsic namelist output
+ shall be suitable for input, except for character
+ output. ...
+ The form of the output produced by defined output (9.6.4.7)
+ is determined by the defined output procedure; this form need
+ not be compatible with namelist input."
_______________________
> For characters you need to use one of
> the delimited forms for the strings (I'm not sure about
> strings that contain internal quotes and wrap over several
> lines). For user defined namelist I/O you just have to
> write the output and input routines to be aware of what each
> other is doing--that's no different from normal I/O. I
> think all of the non-character intrinsic types now produce
> output that is inputable.
>
> Also, namelist was only standardized in 1990, so it's only
> been 13 or 18 years, not 40 ;).
NAMELIST has been around since the 1960s, at least.
Since there was comparison with PL/I, I point out that
the output from the equivalent PL/I has always been compatible with input.
robin
> I suppose just about anything except reading in a format string.
Even that can be done in PL/I via the EDIT builtin function.
> You can do many strange things with the R (remote) format
> descriptor and LABEL variables.
>
> Also, the differences are enough to wonder about those who thought
> PL/I could replace Fortran (Fortran V, or so).
Obvious differences are for COMPLEX values and LOGICAL values.
Both these are trivially duplicated by PL/I.
The main differences were the inclusion (in FORTRAN) of character
strings in FORMAT statements. That was a carryover from an archaic form
of text handling.
That can be handled in PL/I in most cases trivially.
Other exotic forms require some careful translation.
Certainly the FORTRAN output forms were (still are) easily (trivially)
reproduced by PL/I, and the Fortran forms can be read in
easily enough.
I do not recall seeing any documentation about doing an
equivalent in PL/I, although there was a book published
under the title of "Fortran to PL/I converter" or similar.
In recent years I have heard that IBM produced in the '60s a
FORTRAN to PL/I converter program, but if it exists,
I have never seen it.
Dick Hendrickson
Some user control is awkwardly available. You can replace a
variable by F(variable) in an output lost and the function
can do whatever you want as long as it returns a character
string. It's so close to defined output; the only real differences
are the need to return a character string and the lack of magic
access to the dozen or so I/O control thingos.
I suspect that defined I/O wasn't extended to the intrinsic types
because of lack of time and revulsion. The current defined I/O
feature had several different forms before it was perfected and
there (probably) wasn't time to also do it for intrinsic types.
There was also tremendous pressure against overriding intrinsic
operations. Mostly, this came from vendors who had to maintain
commercially successful optimizing parsers and absolutely refused
to allow intrinsic operations (like 2 + 2) to be user redefinable.
I think this attitude carried over to other cases of redefining
an otherwise intrinsic operation.
Dick Hendrickson
John W Kennedy
Yes, along with COBOL-to-PL/I and ALGOL-to-PL/I.
Peter Flass
You wouldn't want to see it. It's mostly written in PL/I that looks
like Fortran, with a piece of the worst assembler code I have ever seen
to handle BDAM files. It's probably easier to write something from
scratch than to try to port this pig.