Post by r***@gmail.comJust to refocus this thread on technical concerns ....
Overall, it doesn't really matter. Small changes like this are the least
of anyone's worries.
Have you heard of TQM? Or Six Sigma, Kaizen, Lean?
These are quality management methodologies whose aim it is to reliably raise quality to levels so close to 100% that it is for all practical purposes indistinguishable from 100% even if 100% is not actually reachable.
Six Sigma for example sets a goal of 99.99966% quality or 3.4 defects in one million opportunities. When you get so close to 100, the weirdest things happen. If you are coming from a natural science background, a good analogy might be quantum mechanics. Observable events simply seem to defy common sense.
For example, a car factory under such a quality regime might find that their quality significantly dropped below target after they changed the subcontractor who cleans the towels for the towel drums in the bath rooms. Nobody can figure out what's wrong with those towels, they seem just fine, but the change in the towel cleaning firm messes up the quality of the cars made at the plant.
It would seem totally whacko but this is the kind of thing you will observe when taking quality to the extreme. There is nothing that can be ruled out as "doesn't really matter". Everything has a potential effect on the product. Everything matters, no matter how tiny.
The management methodologies deal predominantly with measurement and attitude. Since you cannot really predict what whacko thing will mess up your quality target, you need to cultivate an attitude where everyone is alert and nobody considers anything as "doesn't really matter".
We have taken that attitude to heart during our revision and design. To us, every tiny little whacko thing matters. If we can avoid only one bug in 1 million lines of code by reducing every imaginable ever so tiny opportunity for error/defect, then it will have been worthwhile the bother.
Before this background, prefix literals belong to the more important changes in our revision and they will have a significant impact, regardless of what some people who have expressed opinions to the contrary here think. You are entitled to your opinion, but can you present any scientific research to back it up? We have spent quite a bit of reading over the yeaars on various research that has led us to accept that these types of design decisions have an impact significant enough to bother.
Last but not least, mental load is something that adds up, little by little. Small distractions lower our ability to handle mental load. Being tired or frustrated about something will further lower it. An ever so slightly distracting feature in a notation that didn't cause a bug on a good day will cause a bug on a not so good day. It is all about reducing opportunity for error/defect.
Post by r***@gmail.comI still prefer 0--h for hex, but that's just me.
Not all suffixes are equally bad. I'm afraid to say so, but classic Modula-2's suffix literals feature an accumulation of the worst possible design choices.
Digits 0-9, capital A-F and H all have a similar visual footprint, using the full ascent and filling every corner of the bounding box. This makes the H suffix blend in with the digits. It doesn't stand out at all.
By contrast, in traditional assembly notation, where the base-16 specific digits A-F are also capitalised but a lowercase h is used, the h has a much smaller footprint because although it uses the full ascend, its ascender is but a single arm and it doesn't fill every corner of the bounding box. This makes the lowercase h stand out significantly better than the capital H.
In other words, 123Fh is far better readable than classic Modula-2's 123FH.
Likewise, 0abcdh is far worse than 0ABCDh.
For the same reason, 0xabcd and 0XABCD are both far worse than 0xABCD.
And the same holds true for decimal numbers with exponents: 1.23e45 is better than 1.23E45.
The low readability is greatly exacerbated by the fact that the suffixes for base-8 literals are also valid digits in base-16 literals in classic Modula-2. This is the WORST design for literals of any kind in any programming language.
This could of course be eliminated by simply removing base-8 literals, but then you still need to switch from H to h and once you have done that, its incompatible anyway, so you may as well go a little further still and use prefix literals. As I said, it is all about reducing every possible opportunity for distraction and ultimately error/defect.
Also, in embedded development (which is one area we specifically wanted to support) it is quite common to use binary literals. When you add those, then there is the question what suffix to use. If the letter B is to be used, again, 0110b is far better than 0110B, especially so since B is also a valid base-16 digit. But here again, once we've broken compatibility we may as well go the whole distance and use prefix literals.
Last but not least, you want to use a different prefix or suffix again for character code points. If you were to use the letter C, it should at least be lowercase: 040c is far better than 040C for the aforementioned reasons. But if you swich the radix and keep the same suffix, there is great potential for confusion about the radix. In the days of unicode we may as well use the letter U though and again, lowercase is better than uppercase for prefixes/suffixes. 040u or 0u40 is better then 040U or 0U40.
Post by r***@gmail.com0x and $ in Intel assembly, but I always found it odd. The overwhelming
majority seems to prefer 0--h there. Of course, I also shun AT&T syntax,
but some people still prefer that (even though GAS has supported both
since many years), so who knows.
With non-letter prefixes or suffixes it is difficult to find three separate and distinct symbols (base-2, base-16, unicode) you could use as prefix or suffix and still have some mnemonic value to hint at the meaning. However, non-letter prefixes and suffixes have the advantage that they stand out more. There you have to make a trade-off between mnemonic value and visual cue value.
Post by r***@gmail.comHow does Ada do it? A quick search shows 16#FF# for 255. Similar (but
not quite) to Extended Pascal (16#FF) and Modula-3 (16_FF).
Indeed, Ada, Extended Pascal and Modula-3 all use PREFIX literals.
Their designers all made that "totally bogus" choice.
Perhaps it was the other way round and Modula-2 took the odd choice here.