(j3.2006) (SC22WG5.5769) RE: Other languages with unit support

[Whitlock, Stan]

So what?  How much use do these systems get?  What per centage of important HPC code is written in these systems?  Weather forecasting?  Oil exploration?   Car crashing?  Nuclear bomb design?  Space flight?  Financial crunching?  Another meaningless non-justification for units in Fortran.

When enough important customers {plural} are will to say to vendors that they want units in Fortran over coarrays or submodules or C interoperability, then vendors will have the data they need.

I echo Bill?s sentiment ? you need to stop crying in the wilderness about units.  The majority is unconvinced, you lost the argument, please stop beating a dead horse.

/Stan

From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Van Snyder
Sent: Saturday, July 09, 2016 7:07 PM
To: sc22wg5 <sc22wg5 at open-std.org>
Subject: (j3.2006) (SC22WG5.5767) Other languages with unit support

According to Orchard, Rice and Oshmyan, these languages have units support:

F# (functional)
Haskell (functional)
ML (functional)
Fortress (abandoned in 2012)

Others have reported choosing Mathcad instead of Matlab because it has unit support.

Does anybody use any of these languages for serious scientific and engineering programming?  I.e., for something other than prototypes, toys, or small problems?

There is a C++ library at http://tuoml.sourceforge.net/.  From the first page:
The purpose of this library is to try to make it more difficult to make coding mistakes that incorrectly mix units of measure. This is done with a set of C++ classes that provide type-safe manipulation of units of measure for various properties. The classes provide compile-time units checking as opposed to run-time checking.

Compile-time checking is far less difficult and expensive to track down errors. For example, if the developer tries to mix feet and meters, a compile-time error will result. Without the type-safe classes, this error would not be found until run-time (if at all!).

Extreme care was taken in designing this library so that the run-time execution using the classes does not suffer any penalty versus using native double precision types. For instance, the classes have no virtual functions, so the compiler does not generate a virtual table. The resulting memory footprint of the class is therefore the same as a double. And since the type checking is done at compile time, there is no run-time performance hit when using the classes.

Grant Petty provided a module for units computing in Fortran.  It imposes significant runtime overhead.  It doesn't support conversion, which would make it bigger and more expensive to use.

Osprey is a units checker for C programs.  I suspect it doesn't provide conversion, or input checking.

SimCheck is a units checker for Simulink programs.  I suspect it doesn't provide conversion, or input checking.

But I guess nobody wants support for units.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20160710/6c6dd13f/attachment.html