Re: about some potentially interesting unicode operators

On 29/08/2024 02:04, Keith Thompson wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Wed, 28 Aug 2024 12:46:55 -0700, Keith Thompson wrote:

A problem with using non-ASCII Unicode characters as operator names is
that they can be difficult to type -- and the way you type them is
inconsistent across systems.

>
The best way is the Compose key available on *nix systems. This is the
closest to a mnemonic-based system that reduces the burden on your memory.
>
<https://wiki.wlug.org.nz/ComposeKey>

 There is no "Compose" key on the keyboard I'm using to type this.
There is a key labeled "Alt Gr", but it doesn't appear to behave in
any consistent or useful way.  (I'm using a Windows laptop; "Alt Gr"
doesn't appear to do anything useful even in Windows PowerShell.)
 

The Alt-Gr key works differently depending on the keyboard layout. Typically you need to choose some kind of "international" layout to get a distinction between Alt-Gr and Alt.  Then you have easy access to a fair number of additional characters, even ones that are not required for the language you use.  The disadvantage is that some keys become "dead" keys, especially for accents and other diacriticals.  So if you pick "international" versions of the US or UK keyboard layouts, rather than the standard ones, you get some Alt-Gr characters.
However, even with that, Windows keyboard layouts are quite limited compared to Linux.  And you don't have a Compose key on Windows.  (If I'm wrong there, I'd be happy to be corrected!).  Most Linux keyboard layouts don't have a Compose key by standard either, but it's generally a simple setting to change that (I usually use Scroll Lock as a Compose key).
Even when you are able to type extra operators or symbols, it's often hard to read them (assuming in the first place that you are using a font that supports them - this can also be an issue, especially on Windows). I can type "x ← y" quite easily (it's shift Alt-Gr i) but I find it a lot harder to read than "x <- y" would be at the same font size.

If there's an easy way to type non-ASCII characters like '·' that
works across different systems, including all the various terminal
emulators used on Windows and Linux (as well as MacOS, but I don't
happen to use it), I'd love to know about it.  (I obtained that
'·' character by opening vim, entering the Ctrl-K . M digraph,
and copy-and-pasting into this window -- not something I'd be
willing to do every time I want to type an operator symbol.)
 People who use non-English languages typically have keyboards with
accented letters and so forth.
 

There's nothing wrong with using identifiers as operator names.
C already does this with "sizeof" et al.

>
Except they add to your list of reserved words.

 That's not much of a problem if they're designed into the language from
the beginning.  (I'm not suggesting adding new keyword operator symbols
to C -- though C has been acquiring new keywords, including alignof
which is an operator and typeof which resembles one.)
 

Too many reserved words in a language quickly becomes a problem.  It can get in the way of picking sensible identifiers for your own usage, and because a real issue when you want to add more in the next language version.
What makes more sense, IMHO, is to design the language in such a way that you can have user-defined operators (prefix, postfix and infix) with either alphanumeric or punctuation, and a language syntax and grammar that can distinguish them from other types of identifiers even if the names crash.  You might still get occasional ambiguous parses, but that can be a compile-time error.
And if these are all user-definable, then they are also definable in the language's standard library.  Then code can pull in the operators it needs without any others, and it's easy to have aliases such as unicode symbols and alphanumeric names.