Adding Unicode operators to D

[Charles Hixson]

Bruno Medeiros wrote:
> Andrei Alexandrescu wrote:
>> Spacen Jasset wrote:
>>> Bill Baxter wrote:
>>>> On Thu, Oct 23, 2008 at 7:27 AM, Andrei Alexandrescu
>>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>> Please vote up before the haters take it down, and discuss:
>>>>>
>>>>> http://www.reddit.com/r/programming/comments/78rjk/allowing_unicode_operators_in_d_similarly_to/ 
>>>>>
>>>>>
>>>>
>>>> (My comment cross posted here from reddit)
>>>>
>>>> I think the right way to do it is not to make everything Unicode. All
>>>> the pressure on the existing symbols would be dramatically relieved by
>>>> the addition of just a handful of new symbols.
>>>>
>>>> The truth is keyboards aren't very good for inputting Unicode. That
>>>> isn't likely to change. Yes they've dealt with the problem in Asian
>>>> languages by using IMEs but in my opinion IMEs are horrible to use.
>>>>
>>>> Some people seem to argue it's a waste to go to Unicode only for a few
>>>> symbols. If you're going to go Unicode, you should go whole hog. I'd
>>>> argue the exact opposite. If you're going to go Unicode, it should be
>>>> done in moderation. Use as little Unicode as necessary and no more.
>>>>
>>>> As for how to input unicode -- Microsoft Word solved that problem ages
>>>> ago, assuming we're talking about small numbers of special characters.
>>>> It's called AutoCorrect. You just register your unicode symbol as a
>>>> misspelling for "(X)" or something unique like that and then every
>>>> time you type "(X)" a funky unicode character instantly replaces those
>>>> chars.
>>>>
>>>> Yeh, not many editors support such a feature. But it's very easy to
>>>> implement. And with that one generic mechanism, your editor is ready
>>>> to support input of Unicode chars in any language just by adding the
>>>> right definitions.
>>>>
>>>> --bb
>>> I am not entirely sure that 30 or (x amount) of new operators would 
>>> be a good thing anyway. How hard is it to say m3 = 
>>> m1.crossProduct(m2) ? vs m3 = m1 X m2 ? and how often will that 
>>> happen? It's also going to make the language more difficult to learn 
>>> and understand.
>>
>> I have noticed that in pretty much all scientific code, the f(a, b) 
>> and a.f(b) notations fall off a readability cliff when the number of 
>> operators grows only to a handful. Lured by simple examples like 
>> yours, people don't see that as a problem until they actually have to 
>> read or write such code. Adding temporaries and such is not that great 
>> because it further takes the algorithm away from its mathematical form 
>> just for serving a notation that was the problem in the first place.
>>
> 
> But what operators would be added? Some mathematician programmers might 
> want vector and matrix operators, others set operators, others still 
> derivation/integration operators, and so on. Where would we stop?
> I don't deny it might be useful for them, but it does seem like too 
> specific a need to integrate in the language.
> 
> 

Perhaps what needs to be added is a syntax for defining character to 
function correspondence?  That way people could define the binary 
functions that they need, and then define a corresponding character 
string that represented it.  I once recommended that Eiffel include a 
means of defining user operators (i.e., binary functions that sit 
between the terms on which the operate) using the name syntax thusly:

Starts and ends with '|' and doesn't contain any whitespace.  Must be 
surrounded by whitespace when used.  I.e. 1 |X|-3 would be forbidden, as 
there is no whitespace following the |X| operator.

That still seems like a good rule to me.  If you want to include 
unicode, that's no problem.  And the function could also be used as:
    X(1, -3)
with identical meaning.  I.e., marking a function as an operator by 
surrounding it with pipes would be purely syntax sugar.  Note that such 
operators would have a precedence higher than assignment, but lower than 
everything else, so in practice the choice would be between writing:
   X (1, -3)
and writing:
   (1 |X| -3)
unless all one were doing is making an assignment.  This is analogous to 
the class member variable in object methods, or the class name in class 
methods, except that that is often understood.

OTOH, I'm not certain how much such syntax buys you.

P.S.:  another possibility, which is more in line with current D syntax 
requires an assignment of the operator character to a function that 
starts with op.  As in '+' is associated with opAdd.  However even 
though this is more in line with current D syntax, it seems to buy you a 
lot less.  And it seems to require that the operator be a single 
character.  This appears to me to be more work than it's worth for the 
return.  Even the approach that I suggested is probably marginal.

P.P.S:  Any system that requires that a specific IDE or editor be used 
is no going to work.  Not unless the IDE were provided with the 
language, and even then the most successful examples I can thing of are 
EMACS and Smalltalk.  (I'm excluding programs that don't run on Linux, 
as I have no familiarity with either how they function or how popular 
they are.  Probably, though, one could include Visual Basic and maybe 
some others.  But one certainly couldn't include Basic, merely one 
dialect of it.)