[J3] 18-156

Tue Feb 27 10:12:13 EST 2018

And units were on my list of 5 items written in response to Steve?s request at the beginning of meeting 215.   Even if it were the case that a units proposal was ?killed at London WG5 meeting,? that was for Fortran 2018. I don?t think that precludes discussing the feature for Fortran 202X.  We don?t seem to be treating other previously rejected proposals that way.

While technically true,  prior ?vigorous" advocacy of this specific feature appears to have poisoned further possibilities at this time.

If I were to rank the features we are discussing based on my own personal use of Fortran in projects and in teaching, I would rank units at the top because I?m already having to roll my own solution in the absence of language support.  I recognize the greater demand for generic programming and better error-handling so I agree with keeping those as the top priorities for major feature addition, but I think units at least deserves a thorough vetting for newer members of the committee who weren?t involved in the discussions of it in years past. Generic programming and improved error-handling appear to have taken top priority for Fortran 202X largely because one of Fortran?s primary competitor languages supports analogous features.  In addition to shoring up Fortran?s deficiencies relative to other languages, I think it?s also important for Fortran to lead and provide features that no other mainstream language supports. The units proposal is one such feature set.

Perhaps I?m overly naive, but the combination of generic programming and ?new types?, should allow a significant portion of the units functionality to developed in libraries.   Adoption of said libraries could lead to demand for a more robust solution in the standard going forward.   Of course ?new types? will also be a large feature and in my estimation at significant risk of not making the final cut for F202x features.

 Can we ever do anything about reliability, and reducing
labor costs?

I sure hope so.  I think greater certainty around program correctness is one of Fortran?s selling points.  (Anyone who has had to deal with memory leaks or dangling pointers in C/C++  will appreciate the increased reliability of Fortran's allocatable variables, for example.)

For the present revision we insist upon use cases. Does anybody have a
use case more extreme than having lost a $200 million project?

There cannot be very many more compelling use cases and it?s frustrating that people dismiss units without acknowledging the high cost of related mistakes.

Just playing devils-advocated here:

My understanding is that while mistakes in physical units were involved in the failure, the mistakes were in _data_ files not in _source_ code.   The proposed feature would then _not_ have prevented the $200 million loss.    Well-funded organizations are free to negotiate with vendors to pay them to implement such features.    And my guess is that the cost for such is significantly less than the price of such missions.    And even without new features, a great deal of protections can be created through libraries at a fraction of the $200 million price of another mission.

I could be dissuaded form supporting units if the cost is higher than the two major feature sets that clearly have the broadest community support (generic programming and better error-handling) or if the performance cost of units is substantial, but I can only come to these conclusions if we can at least discuss the proposal without dismissing it at the very beginning of our deliberative process for 202X.

I too am not opposed to units per se, but it?s not so high on my list of priorities.

- Tom

Damian

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.j3-fortran.org/pipermail/j3_mailman.j3-fortran.org/attachments/20180227/1c057653/attachment-0001.html>