Adding Unicode operators to D

[Steven Schveighoffer]

"davidl" wrote
>? Thu, 23 Oct 2008 09:36:29 +0800,Steven Schveighoffer 
><schveiguy at yahoo.com> ??:
>
>> "Andrei Alexandrescu"  wrote
>>> Correx:
>>>
>>> http://www.reddit.com/r/programming/comments/78rmc/allowing_unicode_operators_in_d_similarly_to/
>>>
>>> Andrei
>>>
>>
>> No thanks.  Please let's only use operators that are on the keys of my
>> keyboard. I don't fancy having to type key digraphs or trigraphs to try 
>> and
>> write code.
>>
>> I understand that others already have this problem, but I don't.  This 
>> would
>> be a huge detractor from D for me.  I'd definitely support a language 
>> fork
>> at that point, or at least refuse to deal with any code that has unicode
>> operators.  I think you'd find others feel the same way.
>>
>> Why can't the emacs module solution work that was used for the cheverons?
>> That is, when emacs sees:
>>
>> x opCross(y);
>>
>> display it as
>>
>> x x y
>>
>> (of course, assume the middle x is the cross symbol, I have no idea how 
>> to
>> type it).
>>
>> And upon save, regenerate the correct code.
>>
>> I see no issue with something like that.  This is all the compiler is 
>> doing
>> anyways...
>>
>
> Everything you worry about is just poor editor. Why do you think an editor 
> can affect the language?

All that is being proposed right now is syntax sugar.  Cross product, dot 
product, union, etc.  All of these will map to a function, so there is no 
reason to require compiler support  (that is, they don't translate directly 
to assembly/machine code).  I'm proposing the editor be used to do the sugar 
instead of the compiler.

Right now Unicode is not universally accepted by all editors, ASCII is. 
Right now, I don't have cross product symbol on my keyboard, all currently 
supported symbols I do have.  Why should my experience with D be severely 
affected by your desire for syntax sugar?

> And It complexes the language, if it's not priorly converted by the 
> programmer. Also it possibly sets up
> future restrictions of extending the language in the correct direction!

Today, I can call opX functions instead of using the appropriate operator. 
This is no different.

> In your case: x opCross(y) , why identifier opCross(identifier) is 
> considered as identifier x identifier?
> So would the typical operator overload function declaration should be 
> considered that way?
>
> x opCross(y)
> {
> }
>
> x x y
> {
> }
>
> or even
>
> x opCross(y, m){}
>
> --->
>
> x x y, m  {}
>
> also consider a template declaration
>
> Matrix opCross(T)(T a)
> {
> }
>
> should it be considered as Matrix x T (T a)?
>
> If not , how do you distinguish in all those circumstances(and not all 
> possible "shouldn't be" situations are listed here)


The editor module would have to be (and can be) smarter than that.

-Steve