(j3.2006) CD ballot process

[Van Snyder]

On Thu, 2017-04-13 at 19:00 +0000, Bill Long wrote:
> > Since Bill led the charge against the proposal to publish a non-binding
> > non-normative description of a system to support measurement units,
> 
> You give me too much credit. 

> > arguing that the facility could be provided by a preprocessor or
> > already-existing mechanisms,
> 
> No. Others might have argued that

On July 10 2016 Bill wrote

        You have uncovered two free packages, CamFort for Fortran and
        tuoml for C++, that provide units support.... So the committee
        can finally stop discussing units and move on.
        
But CamFort does only a small part of the job, and a C++ class library
is irrelevant to a Fortran program.  Neither one are part of any Fortran
processor.

So, will Bill withdraw those grounds for his objections to units, or
support my proposal, on the same grounds, that locality specs are
pointless?  Which way does he want it?

> (since essentially everyone argued against it), but my argument was
> more straightforward.

Nobody argued against it at any meeting.  There was essentially no
discussion at any meeting.  Just votes.  It was favorably received in
2004, but it got pushed off the priority list by 2005, at which time I
was urged to write a TR, which is now apparently anathema.  Those who
did not favor it did not offer a reason.  At the 2013 Delft meeting,
Malcolm objected to interpreting integer division in an exponent in the
definition of a conversion unit as a rational fraction rather than in
the usual way as a quotient without remainder, so I changed that.  On
July 10 2016 Malcolm wrote "Several people have expressed their
discontent with the technical content."  In response I asked "I'd be
interested to know the objections to the technical content" because I
had not seen any other than Malcolm's 2013 remark.  There was no reply.
There were no technical objections stated in N2112.

The delay in implementing Fortran 2003 was somehow a reason.

The low level of requests from applications programmers was another
reason.  Perhaps requests from applications programmers' representatives
to Fortran committees doesn't count.  Would it help if I told my
colleagues and managers to contact compiler vendors directly with all of
their requests, for which I now have 61 pages encompassing 162 requests,
after which they would ask "Why are we sending you to meetings?"  J3
only ever got any significant requests from application programmers when
Walt Brainerd organized the public call for F2008 features in 2004, but
we still do stuff.  Four other languages that are not used for serious
engineering or scientific software have integrated support for units.  A
preprocessor exists that does a tiny bit of the job of supporting units
checking in Fortran.  A C++ class exists.  A Fortran module that has
significant runtime cost exists, but it only solves part of the problem.
I guess none of that indicates interest in solving the problem.

> The implementation and maintenance costs significantly out weighed the
> potential benefit.

Cost was cited in N2112, but without comparison to the cost of any other
feature.  The "configuration file" for my code is a little language that
includes units checking.  The type checker includes a recursive
procedure essentially identical to an expression evaluator that
traverses the abstract syntax tree and computes types and units of
expressions instead of values.  The specification for each input item
includes the type allowed for its value, and its allowed units if it's
numeric.  It wasn't terribly difficult, and hasn't needed much
maintenance.  I suspect processors already have essentially this
infrastructure in place to compute types and kinds of expressions, and
that adding units checking to type and kind checking would not be nearly
as difficult as it's painted to be.  Units checking for arguments, and
for generic resolution, is essentially identical to kind checking.
Processors already allow several kind type parameters for derived-type
objects, so adding something that behaves essentially identical to a
kind type parameter for real objects to represent units doesn't seem
like a giant leap.  Representing the units of a real variable seems to
be a much simpler problem than representing a derived type (at least it
was easy in my configuration file's type checker).

Explicit interfaces arrived in Fortran 90.  Aleks, Dan, and Dick
proposed facilities to improve program correctness that never went
anywhere.  Fortran committes seem to have lost interest in any language
support for program correctness.  Will that ever change?