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

Bill Long longb
Wed Jun 29 18:29:24 EDT 2016

On Jun 29, 2016, at 3:58 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

> On Wed, 2016-06-29 at 12:35 +0000, Bill Long wrote:
>> The implementation costs greatly outweigh the benefit in this case,
>> and vendors are not awash with free resources for such a project. 
> 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. 

> and the benefit is enjoyed
> continuously thereafter by the vendors' thousands of customers.  So the
> question is "what would be the additional cost per customer??  

High when the number of customers is less than ?thousands?. 

> 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.   

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

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.)

> 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. 

> 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 suspect
> there are others in the same boat.  If there were a GNU preprocessor,
> that might make a tiny difference.
> Have I missed something?

The previous iterations of this same discussion, perhaps. 


> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

More information about the J3 mailing list