user-defined operators: a very modest proposal
Tom Anderson
twic at urchin.earth.li
Tue Nov 22 20:35:04 EST 2005
On Tue, 22 Nov 2005 jepler at unpythonic.net wrote:
> Each unicode character in the class 'Sm' (Symbol,
> Math) whose value is greater than 127 may be used as a user-defined operator.
EXCELLENT idea, Jeff!
> Also, to accomodate operators such as u'\N{DOUBLE INTEGRAL}', which are not
> simple unary or binary operators, the character u'\N{NO BREAK SPACE}' will be
> used to separate arguments. When necessary, parentheses will be added to
> remove ambiguity. This leads naturally to expressions like
> \N{DOUBLE INTEGRAL} (y * x**2) \N{NO BREAK SPACE} dx \N{NO BREAK SPACE} dy
> (corresponding to the call (y*x**2).__u222c__(dx, dy)) which are clearly easy
> to love, except for the small issue that many inferior editors will not clearly
> display the \N{NO BREAK SPACE} characters.
Could we use '\u2202' instead of 'd'? Or, to be more correct, is there a
d-which-is-not-a-d somewhere in the mathematical character sets? It would
be very useful to be able to distinguish d'x', as it were, from 'dx'.
> * Do we immediately implement the combination of operators with nonspacing
> marks, or defer it?
As long as you don't use normalisation form D, i'm happy.
> * Should some of the unicode mathematical symbols be reserved for literals?
> It would be greatly preferable to write \u2205 instead of the other proposed
> empty-set literal notation, {-}. Perhaps nullary operators could be defined,
> so that writing \u2205 alone is the same as __u2205__() i.e., calling the
> nullary function, whether it is defined at the local, lexical, module, or
> built-in scope.
Sounds like a good idea. \u211D and relatives would also be a candidate
for this treatment.
And for those of you out there who are laughing at this, i'd point out
that Perl IS ACTUALLY DOING THIS.
tom
--
I DO IT WRONG!!!
More information about the Python-list
mailing list