Operator overloading -- lets collect some use cases

[Don]

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

[snip]

>>>> 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).
>>
>> Could you be more specific about this? For SQL, arithmetic and logical 
>> operators don't seem to be involved. 
> 
> In fact they both can be involved. Below are operators which are 
> understood by SQLite - one of the simplest databases:
> 
> Binary:
>     ||
>     *    /    %
>     +    -
>     <<   >>   &    |
>     <    <=   >    >=
>     =    ==   !=   <>   IN  LIKE  GLOB  MATCH  REGEXP
>     AND
>     OR
> 
> Unary:
>     -    +    ~    NOT
> 
> As you see there are arithmetic operators and as well logical operators, 
> which are used in SQL expressions.
> 
> 
>> The example you gave showed (if I understand correctly) a wish to make 
>> expression templates involving comparison operators, a task which is 
>> currently impossible.
>>
> 
> Why do you mention expression templates? Its not necessary to use them 
> in my opinion. Operator overloading should be just right for this task.

It seems to be the same concept: the == operator does not perform an == 
comparison, rather the return value records the operands which were 
used, and records the fact that an equality comparison needs to be made. 
The actual equality comparison is done later, when the complete 
expression is known (it is done in the SQL statement).

> I see built-in operators overloading as a part of wider category of 
> defining infix functions (eventually also postfix functions).

It seems to be a case where you want an abstract syntax tree.

> Also I would like to add a word to my latest post regarding string 
> mixins as I see I was not clear enough about it. It should be possible 
> to construct queries itself on runtime like below:
> 
> DbTable Person = ....; //In my case DbTable keeps table columns and few 
> other informations
> 
> DbMatrix getPersons(SQLExpression exp) {
>     Query query = Select(Person).Where(exp);
>     return Database.execute(query);
> }
> 
> void main() {
>   SQLExpression exp = (Person.Name == "John");
>   DbMatrix res = getPersons(exp);
> }
> 
> This is what I mean by constructing queries on runtime. With string 
> mixins you will have to do not only mixin(SQL("SELECT ....")) but also 
> mixin(SQLExpression()), what gets really complicated in the end.

No. You can always move the complexity into the mixin string parser.
(since you can get full type information of everything mentioned in the 
string).

BTW, the string mixin is just a temporary evil -- it's a way of getting 
an abstract syntax tree using existing D. It's severely lacking syntax 
sugar.