Adding Unicode operators to D

[Bill Baxter]

On Mon, Oct 27, 2008 at 8:23 AM, Simen Kjaeraas <simen.kjaras at gmail.com> wrote:
> On Sun, 26 Oct 2008 22:28:16 +0100, Bill Baxter <wbaxter at gmail.com> wrote:
>
>> On Sun, Oct 26, 2008 at 11:02 PM, Simen Kjaeraas <simen.kjaras at gmail.com>
>> wrote:
>>>
>>> On Sat, 25 Oct 2008 12:14:47 +0200, Spacen Jasset
>>> <spacenjasset at yahoo.co.uk>
>>> wrote:
>>>
>>>> Why unicode anyway? In the same way that editor support is required to
>>>> actually type them in, why not let the editor render them. So instead of
>>>> symbol 'x' in the source code, say:
>>>>
>>>> m3 = m1 cross_product m2
>>>>
>>>> as an infix notatation in a similar way to the (uniary) sizeof operator.
>>>>
>>>>
>>>> While cross_product is a bit long and unwieldy any editor capable can
>>>> replace the rendition of that keyword with a symbol for it. But in
>>>> editors
>>>> that don't it means that it still can be typed in and/or displayed
>>>> easily.
>>>>
>>>> Another option includes providing cross_product as an 'alias' and 'X'
>>>> aswell.
>>>>
>>>> Which then leads on to the introduction of a facility to add arbitary
>>>> operators, which could be interesting becuase you can supply any
>>>> operator
>>>> you see fit for the domains that you use that require it. -- This
>>>> provide
>>>> exactly the right solution though as all the additions would be 'non
>>>> standard' and I can see books in the future recommending people not use
>>>> unicode operators, becuase editors don't have support for them.
>>>
>>> This made me think. What if we /could/ define arbitrary infix operators
>>> in
>>> D? I'm thinking something along the lines of:
>>>
>>>
>>> operator cross_product(T, U)
>>> {
>>>  static if (T.opCross)
>>>  {
>>>   T.opCross(T)
>>>  }
>>>  else static if (U.opCross)
>>>  {
>>>   U.opCross_r(T);
>>>  }
>>>  else
>>>  {
>>>   static assert(false, "Operator not applicable to operands.");
>>>  }
>>> }
>>>
>>> alias cross_product ×;
>>>
>>>
>>> I'm not sure if this is possible, but it sure would please downs. :P
>>
>> What's the precedence of your user-defined in-fix operator?
>>
>> --bb
>
> Yup, I realized this myself as well. Seemed like such a great idea when I
> only thought of it for three seconds. :p

Same thing goes for downs' in-fix operators.  I think his syntax is
/infix/ which means that his ops always have the same precedence as
division.
I'm guessing this Python Cookbook recipe is very similar to Downs'
technique.  It discusses pros and cons and such.
http://code.activestate.com/recipes/384122/

--bb