(j3.2006) (SC22WG5.5741) Units of measure

[Van Snyder]

On Wed, 2016-06-29 at 22:29 +0000, Bill Long wrote:
> On Jun 29, 2016, at 3:58 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> > I'm not convinced about the relationship of cost to benefit.  Remember
> > that the cost is incurred once by vendors,
> 
> Once? Except for the inevitable changes and enhancements, and the ongoing testing and maintenance costs. 

The development cost is incurred once.  I don't propose to ask for any
extensions to the units system.  I would be surprised if anybolse does.
Have you any in mind?  The only one I can imagine is units for complex
parts, but that seems to be more difficult to define than to implement.
I would expect testing to be essentially automatic, and maintenance to
be small, except for vendors who take a bizarre one-off tack that has no
relationship to exploiting existing language features, such as kind type
parameters, generic functions, and generic resolution.

> > Has any
> > vendor asked its customers "If the language and processor provided
> > automatic units checking and conversion, would that be worth
> > $n/license/year?"  Indeed has any vendor ever asked any customer any
> > such question about any proposed language feature?  I've never been
> > asked.
> 
> Well, for vendors who don?t charge separately for the compiler, this is not a meaningful question. 

If the price is hidden, it doesn't cease to exist.  Does Cray
communicate with its Fortran compiler customers at all?  Has any vendor
asked any customer any such question about any proposed language
feature?  Nobody ever asked me, at least not since the Univac Athena
Fortran developer worked down the hall from me at JPL.

> Is this something that has been added to C++  - a language ecosystem that is much easier to paste something onto?  

That's kind of a pointless question.  C++ wasn't intended for scientific
or engineering computing.  I don't see much use for units of measurement
in a web front end for a database, or a video game.  I would be very
surprised if anybody asked for it in C or C++ (or python, or Java, or
Ruby, or Mumps, ...).  It was requested during development of specs for
what became Ada.  That pillar of wisdom and genius, Col. Whittaker, said
"Huh? Why would we want that in a language intended for high
reliability?"

> I think the more relevant question is how many people are asking for this, or need it.  That number seems to very small. (In my experience, one.)

In 04-245, Dan wrote "there have been several requests for values
specified to have units."  He proposed a system based upon new kinds of
kinds.  I remarked about this as one method to implement parts of my
proposal in my previous message.

Grant Petty requested units support in 04-215, which appeared under
Walt's name because it came via his web page, but without describing it
in detail.

I don't represent only myself.  JPL doesn't pay for my J3 and WG5
participation so I can represent myself.  Do you represent yourself, or
Cray?  You can consider that when I ask for a significant feature, it
came from some significant subset of a thousand or so users at JPL.  

This was the only feature requested in 2004 in three different papers.
But I guess that means nobody wants it.

In 04-265r1 and later spreadsheets through 04-370r2, both 04-215 and
04-245 were linked to my paper 04-122.  The "hate dislike like love"
score for 04-122 was 0-3-7-1, so the sentiment seemed to be 8-3 in favor
of doing it, subject to prioritization.  04-122 was removed from
consideration between 04-370r2 and 04-370r3, without its disposition
having changed from "JoR" to "No Action."  Its impact on the standard
had increased from 5 to 7, without detailed discussion of it.  The only
other proposal to have an estimated impact of 7 was TYPELESS object,
which we went ahead and did; it's clearly a much smaller project than
units or coarrays, which had an impact of 6.  So the "impact on std"
column of the spreadsheets, in retrospect, seems to be quite inaccurate.
If 04-370r2 is sorted in descending order on the "Priority" column,
units are sixth out of 53 items.  It's clear units were removed from
04-370r3 because the impact was overestimated.  I wrote the first TS
proposal in 2009 so that there would be some clearer way to estimate the
impact, but J3 never again discussed it in a meaningful way.  There was
a presentation, followed by blank stares, at the 2012 WG5 meeting.

> > Several developers of preprocessors and analysis products have told me
> > this is not a difficult problem.  
> 
> Then perhaps that?s the solution. Let the few who need this pay for it. 

Let the few who need coarrays pay for it.  Let the few who need PDT pay
for it.  Let the few who need DIO pay for it....  None of my JPL
colleagues ever asked me to advocate for any of these.  We did have Cray
computers with compilers that probably included early versions of
coarrays, but nobody begged me to advocate for standardizing them.  I
don't remember who was the "champion" for PDT or DIO in 1997, but I
don't remember anybody asking for a list of others who wanted them.

> > We don't want to be tied to a
> > commercial product because we have other users of our software who might
> > not want (or be able) to afford the cost of the processor.  
> 
> Ah, so you do want it to be free. 

I didn't say that, and you know it.  I remarked in my previous message
that I would be happy to pay more for my yearly licenses.  I even went
so far as to say it would be worth $100/yr to save $8000/yr, but I doubt
it would cost that much.

The people who use my software are happy to pay for a Fortran compiler
license, and would probably not be terrified by a few extra dollars per
year to pay for units support.  How many users pay a few extra dollars
per license but never use a WHERE construct or submodules? They don't
want to have to buy a different preprocessor for every different useful
feature that the Fortran committees refuse to provide but their software
suppliers use, or five different preprocessors for one feature that the
standard doesn't provide, but that is provided slightly differently
(i.e., not standardized) by preprocessors necessary to compile software
they receive from five different sources.  This is why I don't use a
preprocessor, and neither does almost anybody else, unless it's embedded
in the processor and pretty-much standard, such as cpp.  Nonstandard
preprocessors never were and never will be a widely-viable solution to
any significant problem.  They are proof-of-concept toys and nothing
more.  If preprocessor vendors say units are not a significantly
expensive problem, why are compiler vendors saying it is?  Perhaps
compilers aren't designed with mutability in mind, notwithstanding ISO
expects us to revise the standard every five years.

If you really want a preprocessor to be a solution to this problem, stop
opposing publishing the TS as a quasi-standard for how to do it,
including especially opposition to publishing it without the promise to
implement it.  At least then the preprocessor(s) could all be expected
to do it the same way, and ones that don't conform to the TS probably
wouldn't go anywhere.

> > Have I missed something?
> 
> The previous iterations of this same discussion, perhaps. 

The previous iterations of this discussion have not been illuminating.
All handwaving about "enormous expense" and "nobody wants it."  They did
not address any part of the discussion of my vision of how it might be
implemented, to which the "Have I missed something?" question was
directed.  Your snide reply doesn't address any part of that discussion.

The real question is whether the Fortran standard cares about
reliability.  Once we got explicit interfaces, we seem to have stopped
dead in our tracks on the reliability front.  Dan requested an ASSERT
statement in 04-142.  Aleks advocated for features for programming by
contract, a la Eiffel, but without much specific detail.  Those went
nowhere also.  There was no porposal remotely related to reliability in
05-010, nor in 15-010, except maybe IMPLICIT NOEXTERNAL.  Can we do
something in this direction in the next revision, or are we stuck
forever on performance?  It is actually important to get the right
result, not just to get some result quickly.