(j3.2006) Seeming problem with NAMELIST output of charactervariables

[Malcolm Cohen]

>I got an interesting test case that exposed what seems to be an unfortunate 
>consequence in the standard.

It is not a "consequence".

>9.5.6.8 says that the default for the DELIM= specifier is ?NONE? in an OPEN 
>statement.

>10.10.4 says that list-directed output of character values when DELIM is 
> ?NONE? does not include enclosing quotes.

Fortran 95 directly states that this occurs when there is no DELIM= specifier.

>10.11.4.2 says that namelist output editing is the same as for list-directed 
>output.

Fortran 95 directly states the result (it does not refer to list-directed).

> And NOTE 10.39 says that DELIM=?NONE? [which is the default]  will output 
> character values that cannot be read by a namelist read.

That's "might not be acceptable as namelist input" (spelled "may..." in Fortran 
95).

>So, in the default case (no DELIM specified in OPEN) we have the situation that 
>namelist output of character data cannot be read by a namelist input statement. 
>Which is an unexpected situation for many users.

>Did we really intend that this be the case?

Whether we really intended this, this is Fortran 90.  So approved 23 years ago 
and unchanged since.  Even though we made other changes to namelist (we added 
namelist comments).

And obviously we DID intend this, indeed the text states it directly (originally 
not as a consequence, that is a result in F2008 of text merges and 
simplifications), and the NOTE is ample evidence we knew what we were doing. 
Some might consider that decision mistaken, but that was the decision 
nonetheless.

>At least one compiler (gfortran) ignores this combination of rules and includes 
>the ? ? around character values in namelist output, which is what the user 
>wanted/expected.

If there is no OPEN statement for the file, or the user does not want to change 
the behaviour of list-directed output, he can put DELIM='QUOTE' into his 
namelist output statement.

(oh, and this is not an "extension", it is giving the wrong answer; extensions 
are when things are upwards compatible.)

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.