Steven D'Aprano wrote:
I cannot wait for the day that we can use non-ASCII operators. But I don't think that day has come: it is still too hard for many people (including me) to generate non-ASCII characters at the keyboard, and font support for some of the more useful ones are still inconsistent or lacking.
For example, we don't have a good literal for empty sets. How about ∅? Sadly, in my mail client and in the Python REPR, it displays as a "missing glyph" open rectangle. And how would you type it?
I will just share my view on the whole problematic, trying to concentrate more on the actual code look. So I see it all as a chain of big steps, roughly: 1. One defines *the real code* or syntax, this means: One takes a pen and a paper (photoshop/paint bucket) and *defines* the syntax, this means one defines everything as it is, including pixel precise spaces between operators, punctuation and so on. 2. One develops an application (IDE) which enables you to automatically load code file and (at least) view it *exactly* as you have defined it. 3. Only after that one starts to think about ASCII/unicode/Hangul (forgive me Lord) or whatever someone has defined as something useful/standard.
Java, I believe, allows you to enter escape sequences in source code, not just in strings. So we could hypothetically allow one of:
myobject\N{WHITE SQUARE}attribute myobject\u25a1attribute
as a pure-ASCII way of getting
myobject□attribute
So this actually would be a possible kind of "bridge" from the real code to what is shown up in arbitrary text editing application or a mailing client. In other words, you believe that in Unicode table you'll find something useful for code definition, but I personally would not even start relying on that, also because it is merely down-top problem solving. Mikhail