Operator overloading -- lets collect some use cases

[Andrei Alexandrescu]

aarti_pl wrote:
> 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 ...);

That's not quite elegant. What if there is a symbol called Name in 
scope? This will confuse the parser to no end. (I forgot to mention that 
in the sub-token approach you'd still have to write the underscore when 
issuing a call.)

Andrei