Operator overloading -- lets collect some use cases

downs default_357-line at yahoo.de
Mon Dec 29 00:40:03 PST 2008


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.



More information about the Digitalmars-d mailing list