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

[Whitlock, Stan]

See my comments embedded below.			/Stan

-----Original Message-----
From: j3-bounces at mailman.j3-fortran.org On Behalf Of Van Snyder
Sent: Sunday, July 10, 2016 3:41 PM
To: j3 at mailman.j3-fortran.org
Subject: Re: (j3.2006) (SC22WG5.5769) RE: Other languages with unit support

On Sun, 2016-07-10 at 14:22 +0000, Bill Long wrote:
> On Jul 10, 2016, at 12:04 AM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:
> 
> > On Sun, 2016-07-10 at 04:38 +0000, Whitlock, Stan wrote:
> > 
> >> 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.
> > 
> > You guys asked for evidence that people want support for units checking.
> > I did a little bit of checking and found a little bit of evidence.  
> > Now you tell me to shut up.  When I find more, instead of saying "shut up"
> > will you start shouting?
> 
> I can see a positive outcome of the exercise.  You have uncovered two 
> free packages, CamFort for Fortran and tuoml for C++, that provide 
> units support.  Assuming that NASA is as concerned about units as 
> we?ve been led to believe, these will certainly be required 
> immediately and the NASA problem is solved.  So the committee can 
> finally stop discussing units and move on.  Thanks, Van, for providing 
> final closure on this issue.

I also found five languages that support units.  So somebody else is interested.  Maybe the guys who invented F# or Fortress never asked the Fortran committees for unit support because they never developed really serious science or engineering software.  They might have thought their toys were adequate to solve their toy problems.

It's not finally closed until I can be confident that every preprocessor that supports units does it the same way.  Even if the packages are free, I have to install them.  I doubt any one of them will work on an entire program if pieces of it use one syntax from one preprocessor and other pieces of it use different syntax from a different preprocessor.

Stan> I consider the WG5/J3 side of this discussion closed.  If CalTech/JPL/NASA wants you to check out all of these preprocessors, ok.  Your findings would affect your employer not the Fortran Standard.
End Stan>

The draft TS proposal now in N2113 includes the words from C++ TSs that say "this was never part of a standard and might not ever be part of a standard."  Let's publish it, so that preprocessors can at least say "My product conforms to the TS."

Stan> Are you kidding?  N2113 has not been vetted, edits haven't been checked, it is in no way ready for publication as a TS supported by WG5 even if it never goes into the standard.  And the committee keeps telling you that it doesn't want to do this work.  If you want to publish its contents as a paper in, say, The Fortran Forum, then all these preprocessors will have something to which they can conform.
End Stan>

This still doesn't address the problems inherent in using preprocessors or directives that aren't integrated with the processor.  Using source debuggers becomes more tedious and expensive because line numbers are different.  It's not obvious the decrease in cost inherent in increased reliability is more than the increase in cost imposed by the inability to use debuggers effectively.

Stan> These are not concerns that the Fortran Standard ever has chosen to address even though they have been around since the first debuggers.  Some vendors and third parties have some good interactive debugging facilities but those are and will remain outside the standard.
End Stan>