Operator overloading -- lets collect some use cases

[aarti_pl]

Andrei Alexandrescu pisze:
> downs wrote:
>> aarti_pl wrote:
>>> Andrei Alexandrescu pisze:
>>>> aarti_pl wrote:
>>>>> Don pisze:
>>>>>> There's been some interesting discussion about operator overloading
>>>>>> over the past six months, but to take the next step, I think we need
>>>>>> to ground it in reality. What are the use cases?
>>>>>>
>>>>>> I think that D's existing opCmp() takes care of the plethora of
>>>>>> trivial cases where <, >= etc are overloaded. It's the cases where
>>>>>> the arithmetic and logical operations are overloaded that are
>>>>>> particularly interesting to me.
>>>>>>
>>>>>> The following mathematical cases immediately spring to mind:
>>>>>> * complex numbers
>>>>>> * quaternions (interesting since * is anti-commutative, a*b = -b*a)
>>>>>> * vectors
>>>>>> * matrices
>>>>>> * tensors
>>>>>> * bigint operations (including bigint, bigfloat,...)
>>>>>> I think that all of those are easily defensible.
>>>>>>
>>>>>> But I know of very few reasonable non-mathematical uses.
>>>>>> In C++, I've seen them used for iostreams, regexps, and some stuff
>>>>>> that is quite frankly bizarre.
>>>>>>
>>>>>> So, please post any use cases which you consider convincing.
>>>>>>
>>>>> DSL support in mother language. As an example I can give SQL in D or
>>>>> mockup tests description language (usually also in D - not as a
>>>>> separate script language).
>>>>>
>>>>> In my previous posts I already put few arguments why it is sometimes
>>>>> much more handy to use "DSL in mother language" approach rather than
>>>>> string mixins with DSL language itself.
>>>> I saw that, but few, if any, of the arguments you made apply to
>>>> operators vs. named methods. You argued on string mixins vs. using
>>>> named symbols. In fact one argument of yours works against you as
>>>> there's no completion for operators.
>>>>
>>>> Andrei
>>> I put my argument much earlier in this discussion:
>>> eg. here:
>>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81040 
>>>
>>>
>>>
>>> To sum up: using methods to emulate operators is just completely
>>> unreadable and looks awful. It's very easy to make an error using such a
>>> technique.
>>>
>>> Later, I just replayed to posts convincing that solution for supporting
>>> DSL languages in D is using string mixins. I believe I could provide a
>>> few weighty arguments to support my opinion that it is not always best
>>> solution for this problem. In many cases it is much better to integrate
>>> DSL into D as a kind of API, not separate sub-language. Then we can get
>>> some support from IDE, while using string mixins we probably would get
>>> nothing...
>>>
>>> Best Regards
>>> Marcin Kuszczak
>>> (aarti_pl)
>>
>> Scrapple.Tools uses operator overloading to provide fake infix 
>> keywords along the lines of [2, 3, 4] /map/ (int i) { return 
>> format(i); }, with a simple and convenient syntax for defining them 
>> (mixin(Operator!("map", "something something use lhs and rhs; ")); ).
>>
>> Forcing the end user to write mixin(function()) for such keywords is 
>> *NOT* the way to go, for several reasons: a) it's hard to extend, and 
>> b) it's needlessly verbose.
>>
>> The reason infix keywords are useful, is because they can be used as a 
>> simple way to chain bijective operations together, i.e. a /foo/ b 
>> /map/ c /select/ d. Without infix keywords, this would take the form 
>> of select(map(foo(a, b), c), d), which is an atrocity because it has 
>> to be read in two directions - middle-leftwards for the operations, 
>> and middle-rightwards for the parameters.
>>
>> (and yes, I know it's wrong to rely on operator evaluation order. So 
>> sue me. )
>>
>> Of course, a more convenient solution would be the ability to extend 
>> the D syntax manually, but that's unlikely to appear in our lifetime.
> 
> I sometimes think of a subtoken-based approach, e.g. any function name 
> starting and ending with an underscore is by definition infix. It's the 
> kind of solution that turns Walter's nose so I never brought it up to him.
> 
> Andrei

Maybe:

R op[Infix|Postfix]_Name(A a, B b ...);

with some additional forms for special characters. These special forms 
could be additionally restricted as necessary, so there would be no 
Postfix '&&', but only Infix etc. etc.

Possible examples:
------------------

SqlExpression opInfix_LIKE(string a, string b);
int opInfix_&(int a, int b);
bool opInfix_&&(bool a, bool b);
SqlExpression opInfix_AND(string a, string b);

Below examples for postfix operators; I have not yet idea of syntax for 
calling side:

int opPostfix_+(int a, int b); //for e.g. Reversed Polish Notation
int opPostfix_*(int a, int b);

It seems that prefix will not be necessary, as prefix notation is just a 
standard function call.

BR
Marcin Kuszczak
(aarti_pl)