However, "File99A" (where A is a hex digit) should
sort (much) after both "File99A" (where A is a letter) and "File100".
The only way you can tell "File99(letter)A" apart from "File99(digit)A"
is by giving the two As different codepoints.
And the only way you can tell 7 decimal from 7 hex is by giving 7 to different code points, that is File777 in hex should sort after File999 in decimal.
The proposal doesn't even think about something so simple.
Think it through.
We would also need to distinguish octal digits. And in some circumstances letters above "F" are used for representing numbers with a base above 16.
In fact you can't tell the difference between hex and decimal consistently in printed plain text without some sort of conventional marker, e.g. a leading "0x" or "$" or "&H" or a following subscript "16". Similarly you can't tell the difference between a product code with mixed decimal digits and letters (as long as they don't go above "F") and a hex number without knowing the context.
Using a different coding won't help if the characters *look* exactly the same on the page.
You will still *need* some kind of marker (or strong context) so that the reader can distinguish hex and decimal. That marker is what indicates whether it is hex or decimal.
Are people going to be happy with any programming language in which B12 can be a variable or a hex number but there is no way to tell by looking at at the code? Are people going to be happy with a computer language in which 25 can be either hex or decimal as far as you can tell by looking at the code?
Coding is for people, not computers.
But if, as in current computer languages, there is a marker to tell whether a number is decimal or hex then you don't need separate coding for the letters representing digits. The marker indicates whether the number is decimal or hex.
The proposal also ignores the fact that lower case letters are indeed often used in hex representation.
Jim Allan
