Operator overloading -- lets collect some use cases

[aarti_pl]

downs pisze:
> 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.

Exactly. My first thoughts was to allow defining infix 
keywords/operators in a similar way as today we can define prefix operators:
myFunc a b

or just:
myFunc(a, b);

Why? Because they are use cases where infix notation is much, much more 
natural than prefix notation.

So we still need:

1. a myFunc b	- infix operator
2. a b myFunc	- postfix operator

Ability to define infix operators seems to be most useful right now.

I just didn't want to depress Walter with too high expectations, so 
starting with just oveloading of already existing infix operators like 
&&, || seemed to be a good start :-D

> 
> (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.


BR
Marcin Kuszczak
(aarti_pl)