The Mars Climate Orbiter team would disagree with this assessment...
Thank you for the link, that article nicely illustrates what I meant when I said: "As a matter of fact, you have to ensure that the right things get in, and the right things get out there [the kernel]. What happens inside however is a completely different story." If we may believe the article, that software falls into at least two parts (say, "kernels", "modules", "packages", "libraries",..) connected by some interface. While each team did a proper handling within their part, they did not made sure the they really got (kilometers) what they expected to get (miles). The issue is particularly tricky as at the same time, all modules probably have passed the respective quality assurance tests without any failure...
Ensuring that an equation is dimensionless is sufficient in all cases...
But then again, there would be no need for a unit library after all. But since we both feel the need for such a library, we seem to agree that the handling in dimensionless quantities will not be the overall solution. (Though it is certainly very helpful in specific situations)
of what type the product (2*meter)*(5*Newton) should actually be and how a compiler should tell the difference.
2 is a scalar value and 5 is a scalar value, so 10*Newton*meter is an energy. Torque is a pseudovector, so two value types whose product forms a pseudovector would result in a torque.
Well basically what makes the difference in my understanding is nothing more or less than wether the distance and the force are considered perpendicular or colinear to each other. The "to each other" being the key word here. But then again, how could that relation be encoded independendly in the types of the two scalar quantities (2*meter) and (5*newton)?
No library can substitute for a complete understanding of the problem domain.
Certainly true, but we draw different conclusions. While you insist on making a difference, I came to the conclusion, that both torque and energy should have the very same internal representation. The interpretation of that internal representation then clearly requires the understanding of the domain.
The author states that the intent is obviously F = 2 m kg s^(-2); In contrast to the author, I personally would naturally expect something like: F = 2.0[N]
It would be relatively easy to generate specializations for unit output that address the named derived units in the SI system.
I am afraid, the problem is deeper than that. IMHO and contrary to ad hoc expectations, the mapping of physical quantities to products of exponentials of basic units is not injective. This means the mapping is not invertible. So the mapping generated by the suggested specializations can at best represent a kind of "maximum likelihood solution".
rational exponents....
Some people need them.
Do you know about their background? Could you please elaborate on that? Yours, Martin.