Clive had a few misconceptions about the proposal.

The proposal specifies only intrinsic units Unitless and Radian.

The processor doesn't intrinsically understand the relationships between
any units.  That is the programmer's responsibility.  The processor does
generate conversion functions based upon unit definitions, but these
must be applied explicitly.

Conversions are not automatic, except during formatted input.  Within
expressions, if conversions are needed, they are explicit, using the
function defined by the unit definition.

If a conversion cannot be expressed in the form a*X+b, one can write
generic functions of the same names as the units to convert between, say
Janskys and optical magnitude.  Such functions would not be used for
automatic conversion during input.

There would be no "Fortran convention" for units in formatted files.
Units, if any, would be represented by a string that is the same as the
name of the units of the variable being read.  This seems like a pretty
trivial thing for other programs to include in their output.  Checking
or conversion would occur if and only if there is a "U" edit descriptor.

On Thu, 2016-07-07 at 15:45 +0100, Clive Page wrote:
> Yes I care about software reliability.  I don't feel at all well 
> qualified to respond to this, but so far nobody else on this list has 
> responded (but I see a few follow-ups on details on comp.lang.fortran) 
> so let me give a personal response as best I can.
> 
> I use and write astronomical data analysis software.  Most of 
> astronomical packages that others write are now coded in C or C++ or 
> Java.  Most older astronomers gave up using Fortran during the long gap 
> before Fortran90; the younger ones never considered learning Fortran at 
> all, as far as I can tell.  I seriously doubt whether the addition of 
> this feature to Fortran would be enough to persuade them to switch or 
> learn.
> 
> Most of my own programming, however, is in Fortran, and like all 
> programmers I make mistakes, and hence spend a regrettable amount of my 
> time debugging my own code.  And astronomical calculations are 
> particularly infested with bizarre units.  For angles, astronomers seem 
> unable to lose their addiction to Babylonian notation 
> (degrees:arc-minutes:arc-seconds etc.), but also use radians, degrees, 
> and more.  Dates and times are almost as bad: we use ISO 8601 strings, 
> Julian Dates and Modified Julian Dates (where the base differs by 
> exactly 2,400,000.5 days), years, days, and seconds.  Software that I 
> have written in the last few years has had to cope with all these and more.
> 
> My guess, however, is that no more than 10% of my mistakes involve using 
> the wrong units, and when they occur they are always very evident, as 
> the results are typically out by a factor of some large number like 
> 86400, which even astronomers tend to notice, so they are easy to 
> diagnose and fix.  I don't expect that using a comprehensive units 
> system such as yours would actually reduce my debugging time by more 
> than a one or two percent, nor would it simplify the code.
> 
> I take your point that such a system might have prevented the loss of 
> the Mars Climate Orbiter which was most unfortunate but perhaps almost 
> unique;  I haven't seen any other evidence that mistakes in units 
> generally get through the most basic testing procedures that all 
> software developers use.  Because these mistakes cause effects which are 
> so hard to miss, they almost never escape into production code, in my 
> experience.
> 
> Another problem is the complexity of the whole subject.  I have a little 
> background here as one of the authors of a revision of the standard for 
> FITS files: a data format widely used by astronomy.  Those interested 
> can download it in various formats from
> http://fits.gsfc.nasa.gov/fits_standard.html
> Tables 3 to 6 and the adjacent text reveal some of the complexities 
> encountered in practice.  Most of those designing FITS files try to 
> document the physical units of their data values in one of the approved 
> forms so that they can be understood by humans.  Occasionally someone 
> proposes that FITS-reading software should do automatic conversion using 
> this standard, but I am not aware of any successful attempts to do this. 
>   The phrase "can of worms" springs to mind.
> 
> Your proposals includes, besides simple unit checking, unit conversions 
> in expressions and assignments and a new format for text files with 
> changes to format descriptors.  Units conversion might be feasible in 
> trivial cases, but where it might be most useful, e.g. to covert radio 
> fluxes in say micro-Janskys to optical magnitudes (a negative 
> logarithmic scale, as designed by the ancient Greeks), it requires so 
> much domain knowledge that it really would not be appropriate to put it 
> into a compiler.  I really think that it is hopelessly optimistic to 
> expect such conversions to work in a useful manner.
> 
> For I/O it would be desirable to cover unformatted and stream files, 
> where at least in most cases both input and output are likely to be 
> performed by Fortran programs.  For text files I'm not so sure actually: 
> when I read or write text files it is usually to interface to a human or 
> to some other package, such as another analysis program, a spreadsheet, 
> or database.  The chances of getting these packages to adopt for their 
> CSV files the same convention for units as Fortran are, well, just about 
> zero.
> 
> On the other side of the cost/benefit analysis, I have no idea is how 
> difficult it would be for compiler-writers to implement the current 
> proposals.  It looks to me like a large amount of work.  At present one 
> of the least satisfactory features of Fortran, as seen by a mere 
> programmer, is the large disparity between the standard in theory and 
> that actually usable in practice.  As someone interested in software 
> reliability I try to compile my code using at least two different 
> compilers and compare the results: this means that many nice features of 
> F2003 and F2008 are ones that I still cannot use because they are not 
> provided by enough compilers.  Given the current gap of at least 16 
> years between a standard being defined and all its features coming to 
> the majority of compilers in use, I would hesitate to put in the next 
> standard any features that were going to be expensive to implement or of 
> doubtful value for fear that they might perpetuate or even extend this 
> gap between theory and practice.
> 
> It might be possible to persuade me of the utility of a very much 
> cut-down proposal, just to provide unit checking on arguments of 
> procedures (and function return values).  This would involve the 
> provision by the programmer of a simple tag, a character string, for 
> each actual and dummy argument.  The sort of thing I have in mind is 
> where a function call which at present looks like this:
>    offset_angle = great_circle_distance (ra1, dec1, ra2, dec2)
> might have units tags added like this:
>    offset_angle = great_circle_distance[arcsec] (ra1[rad], dec1[rad], 
> ra2[rad], dec2[rad])
> 
> Just to emphasise: the compiler would not try to understand the string 
> at all, just check that actual and dummy arguments had strings that 
> matched exactly.  It would mean that, say, [rad] would fail to match 
> [rads] or [radian].  Users would soon learn to check the specification 
> of every procedure they called rather carefully and get this right, 
> while programmers could choose any units names they wanted.  Even this 
> simple proposal would impair the legibility of a program; whether the 
> resulting gain in units-checking would be worth it, well maybe.  It 
> would surely be simpler to implement, but I have no idea at all how much 
> work would be involved in even adding this simple units-checking 
> proposal to existing compilers.
> 
> Regards
>