(j3.2006) (SC22WG5.5065) J3 work plan

[Van Snyder]

On Tue, 2013-08-06 at 02:01 -0400, Rafik Zurob wrote:
> j3-bounces at mailman.j3-fortran.org wrote on 05/08/2013 10:48:40 PM:
> 
> > From: Van Snyder
> ...
> > Concerning UK-10.1a (delete arithmetic IF), my colleagues who have
> > millions of lines of legacy code to maintain are concerned about the
> > amount of work this might impose on them.  They like to use "conform to
> > the standard" switches but fear their codes won't compile if they turn
> > on the switch, even if all vendors continue to offer arithmetic IF as a
> > "convenient extension." 
> 
> I don't think anybody would be removing arithmetic IF anytime soon.  We 
> still claim conformance to the previous standards, not just the latest.
> 
> Usually, vendors have switches for "conforms to the X standard" where X is 
> any Fortran standard since FORTRAN 77.  So your colleagues should still be 
> able to compile this legacy code with "conforms to the F2008 standard", or 
> if this really FORTRAN 77 code, "conforms to the FORTRAN 77 standard".

These codes aren't pure FORTRAN 77.  Our legacy codes don't just sit on
the shelf and only need to be compiled whenever a new computer is
installed.  Many of them have been under continuous development for more
than fifty years.  Stuff added since about 1990 uses features of Fortran
90.  Stuff added since 2003 uses features of Fortran 2003.  If Fortran
2015 deletes arithmetic IF, compiling this legacy code will require
either not using features beyond Fortran 2008, not specifying "conform
to the Fortran 2008 standard" if features newer than 2008 are used, or
getting some money from Santa Claus or the Tooth Fairy to revise the
code not to use arithmetic IF.  The US Congress has been begged
repeatedly to continue funding for legacy software maintenance.
Actually, NASA HQ has been begged.  I don't know whether the requests
died there, or in Congress.

Some processors have hundreds of switches, so one that says "Conform to
the 2015 standard, but don't gripe about arithmetic IF" might be
forthcoming.  It's not good enough that only one vendor does that,
however, since some of the codes have many users, who have different
(and reasonable) reasons for using different processors.

> One advantage of deleting these features (from my point of view as a 
> compiler developer) is that we don't need to make sure (or even test) that 
> new features work with deleted features.

Then we can't use new features in legacy code without revising them to
replace deleted features, or we have to abandon conformance switches.
When six million lines of legacy code were first compiled with the
"conform to Fortran 95" switch, there were no error messages about
PAUSE, and a few hundred about ASSIGNED GO TO.  Revising codes to avoid
these didn't cost much.  There will be thousands, maybe tens of
thousands, when arithmetic IF is deleted.

> This is not the case with 
> obsolescent features, which are still part of the standard.  For example, 
> alternate return is an obsolescent feature, but a user on 
> comp.lang.fortran thought of a way of using it with type-bound procedures 
> to simulate exceptions:
> https://groups.google.com/forum/?fromgroups#!original/comp.lang.fortran/9p7ArVmpxPo/9C9ohHuval0J

This is not a new idea.  I argued when alternate return was put into
small type that it ought not to be deleted until an intrinsic exception
mechanism was put into place.  The way the call stack is unwound is to
have the alternate return label in the CALL statement be the label of an
alternate return statement.  Apparently, this is too inefficient to do
automatically.

John Reid proposed a block-structured exception scheme for Fortran 95,
but it missed the train, and never came back.  Maybe that was a good
thing, since it ought to be based on an enumerated type accessed from an
intrinsic module, not on C-interopreable enums (which are integers, not
a new type).

> Regards
> 
> Rafik
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3