Re: NAMELIST questions raised while testing it's use in parsing ?command line arguments
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.
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
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
> "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
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.
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.