[J3] paper 19-212r.txt contains partially incorrect information

[Bill Long]

> On Mar 8, 2020, at 9:04 PM, Steven G. Kargl via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> On Sun, Mar 08, 2020 at 07:22:25PM -0400, Steve Lionel via J3 wrote:
>> On 3/8/2020 12:38 PM, Steven G. Kargl via J3 wrote:
>>> Paper 19-212r1.txt contains a table that includes information
>>> about gfortran's behavior with the example program.  That
>>> information is correct only for gfortran 9.2 and older versions.
>> 
>> The information was correct in August 2019, when the paper was written, yes?
>> It's good to know that gfortran now conforms for that case, but do you think
>> that this calls for a revision of the 2019 paper? The feature proposed was
>> accepted as a worklist item, and information about which compilers did what
>> at the time is of historical interest only.
>> 
> 
> What any particular compiler does is probably unimportant.
> I am simply correcting/updating information so J3 members
> can make an informed decision.  Some of the behavior recorded
> in the table for gfortran is due to a happy accident on how I
> implemented BOZ some 15 years agos.  gfortran 10.1 will
> correct those accidents.  All of the compilers in the table
> support REAL*4, that is hardly justification for bringing
> REAL*4 into the standard.

Some background might be helpful here. Initially in the development of the feature list for F202X, the idea of restoring the F08 BITS feature was floated.  This was seen as a “large” feature, not in keeping with the goal of having a small revision.  As a compromise, the proposal you are discussing was offered as an alternative. It was accepted.   In particular, the intent was to standardize common practice in the handling of BOZ constants that had been extensions to the standard for many years in many compilers.   For most widely used compilers implementation involves only removing messages issued when standard-conformance checking is enabled.  This was, indeed, a “small” feature, and promotes code portability (a goal of the standard).   We never envisioned any implementor who supported these features to “undo” them before the new standard was adopted.  


> 
> Of the new features for BOZ in 19-212r1.txt, the one that 
> allows a BOZ in an IO-LIST seems rather dubious.  I cannot
> think a reason why this is needed.

It is pretty common for someone to write a test code confirming how a compiler behaves for a particular situation.  (Such as conforming to F202X.).  Typically a value is created in a variable, and then an output of the form “Got xxxxxx, Expected yyyyyy”.  If what you “got” was supposed to be a BOZ constant, the most natural way to print the yyyyyy is to allow the BOZ constant to be the output list item.  Besides, for a vendor that does not already support this, implementation is pretty trivial. 

Cheers,
Bill



> 
> -- 
> Steve

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425