Operator overloading -- lets collect some use cases

[Don]

aarti_pl wrote:
> Don pisze:
>> aarti_pl wrote:
>>>>> 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.
> 
> Abstract syntax tree can be quite easily created using concepts already 
> existing in D.
[snip]

Of course they can. My point is simply: creating syntax trees is what 
you're using operator overloading for. You're actually not creating 
operations.

>>> 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).
> 
> I don't think it is possible. Imagine that you have additionally 
> OrderByExpression and few others expressions like GroupByExpression etc. 
> Now you parser will have to guess what you need just using one method 
> SQL():
> 
> mixin(SQL("SELECT * FROM a;"));      // result: SelectQuery
> mixin(SQL("Person.Name == i + 5"));  // result: WhereExpression
> mixin(SQL("Person.Surname ASC"));    // result: OrderByExpression
> 
> I wouldn't want to write such a parser. And additionally probably some 
> expressions would be ambiguous.
> 
> But it is possible that I miss something here, so if possible please 
> provide usage examples. You can take e.g. above snippet with passing 
> SQLExpression into function.

You're right, I misunderstood what you were doing.

>> 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.
> 
> I don't know much about what will be cooked in future for D. But 
> listening to proposed features would be definitely interesting  :-)
> 
> BR
> Marcin Kuszczak
> (aarti_pl)