On Sat, Aug 27, 2016 at 03:24:49PM +0900, Stephen J. Turnbull wrote:
If you want to change the *language* you need to provide answers to the following. I have no answers to them that I like, but maybe you can do better.
How about 2.4Gaunitwithaveryveryveryveryveryverylongname?
Why would we care if the user wants to use a long name for their units? We don't care if they use a long name for their variables.
Consider the chemical unit "mol". How do you distinguish "1 mol" from "1/1000 ol"?
The rule is you cannot give unit without a scale factor, and the unity scale factor is _, so if you wanted to say 1 mol you would use 1_mol. 1mol means one milli ol.
Similarly, how do you distinguish "1 joule" from "1 imaginary oule"?
Again, you cannot give units without a scale factor. so 1 joule is 1_J. For one imaginary joule, it would be 1j_J.
These look a little strange, but that is because the use they unit scale factor, which is the one that is currently not in heavy use. Other scale factors look much more natural. For example, 1 milli mol is 1mmol. 1 kilo joule is 1kJ.
If you allow both naked prefixes and prefixed units, how do you distinguish "1/10 a" from "10" when both are represented "1da"?
I suggest that we do not support the h (=100), da (=10), d (=0.1), or c (=0.01) scale factors. The primary supported scale factors should be TGMk_munpfa. The extended set would include YZEP and zy.
One last thing, we can accept 273K as input for 273,000, but when we output it we must use k to avoid confusion with Kelvin (and because that is the standard).
I think that's unacceptable. If "273K" has the valid interpretation "0 degrees Celcius" and we're going to accept units at all, we must not ask users to type 273000mK or even 2730dK. So if we ever accept "1K" to mean 1000, we're kinda hosed for accepting units. I think units syntax is broken anyway per the examples above, and Guido already pronounced on "naked scale prefixes":
The valid interpretation of 273K is 273,000. If you want 273 Kelvin, you would use 273_K.