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