Thank you very much for your reply. The thread you pointed out discusses many of the key issues programmers care about in using Unicode operators and identifiers.

You point to a very on-topic thread but the thread leaves out the following:

MATH IS EASY-- JUST ALLOW UNICODE SYMBOLS in IDENTIFIERS

Unicode defines a group of codes called "Math Symbols". Surely this could be allowed in identifiers or even treated as having precedence equal to + or -, both unary and binary.

PARSE UNICODE

Alternatively, declare operators as xf or fx or xfy or f(x,y). Sicstus and Quintus Prolog both allow operators to be declared xf or

xfy or fy. The precedence is between 0 (with the large-scale grouping

power of parentheses) and 1000 (tighter-binding than x^y).

But it takes

effort to write a parser, and the Math symbols beg for a standard

interpretation.

STANDARDIZE UNICODE PRECEDENCE

Over ten years, the Unicode consortium might converge on a standard for treating characters as "things" or "operators", assign them unary or binary, and determine the precedence. The consortium isn't interested? Then it's not a standard. It's ad hoc. In fact, the "right" Unicode approach is a black hole. One can say "we're not ready to do it 'right'" for years.

No one seems to know: If I create f# as my output, how does one make sure the programmer can still look at and debug using the same file they wrote originally? I know what to implement in intellisense.

Best current possibility I know of: emit virtual machine object code or create and interpret C#'s lambda expression trees. (Someone probably knows better).