(j3.2006) (SC22WG5.5747) Units of measure

[Bill Long]

On Jul 3, 2016, at 1:16 PM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:

> On Sun, 2016-07-03 at 11:30 -0400, Tom Clune wrote:
>> a shorter  cycle would provide the greatest opportunity to ensure that
>> the priority list is optimized across the Fortran community and
>> implemented in time to make corrections in the subsequent standard.
> 
> I was expecting a shorter cycle after 2008, but we spent several years
> on WG23 nonsense.  We delayed gathering new features for three years,
> and then did it in a helter-skelter manner that was nothing like the
> organized way we did it in 2004.  Can we not do that again?
> 

I don?t think blaming WG23 is fair.  The committee as a whole did not spend that much time on WG23 activity, it did not create an imposition on vendors, and it seemed like  the right thing to do as being responsible members of the programming languages community. 

The ?delay in gathering new features? , by which I assume you mean ?other than the two TS projects?, fits in with the actual topic of Tom?s post on ?slowing the pace?.  Which, I can verify, the management of at least one vendor vigorously agrees with. 

We need to keep in mind the point of a new revision of the language.  It is to evolve Fortran to keep it relevant in the face of external changes. Particularly things like new hardware environments (parallel processing being a clear example),  or better programming methodologies (block structure, modular programming design with name-space protection, ?).   We also should keep an eye on the evolution of application areas where scientific computing is important (traditionally it was physics, and fields that are essentially applied physics such as chemistry, meteorology, materials science, structural engineering, etc.,  but maybe in the future more biology or cryptography, for example). 

The point of a new revision is not to just add more features for the sake of adding more features.  There are scores of features that have been proposed in the past and rejected.  Unless they meaningfully address something that has since changed in the computing landscape, the argument for rejecting them will not have changed.  we should resolve to not reconsider such features yet again. That would save time for considering things that are relevant to the goal above, and an important component of doing things in an ?organized way?.   Dan has hinted that new features for the next revision should have a more developed justification than the ?this is a cool idea? that we?ve seen in the past. I agree this is the better approach. 

Cheers,
Bill

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

Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101