Operator overloading

[Don]

aarti_pl wrote:
> Don pisze:
>> aarti_pl wrote:
>>> Andrei Alexandrescu pisze:
>>>  > We're trying to make that work. D is due for an operator overhaul.
>>>  >
>>>  > Andrei
>>>
>>> Is there any chance that we get possibility to overload "raw 
>>> operators", like in C++? I think that they may coexist with currently 
>>> defined operator overloads with simple semantic rules, which will not 
>>> allow them to work together at the same time.
>>>
>>> I know that they may obfuscate code, but they are extremely useful 
>>> when defining in D domain specific languages. For example I try to 
>>> make SQL expressions work as D expressions:
>>
>>>
>>> string query = "SELECT * FROM a WHERE id=5;";
>>> -->
>>> Query query = Select(a).Where(Equals(id, 5));
>>>
>>> * "id" is D object in second expression
>>>
>>> This translation is quite awful and unreadable. It would be so much 
>>> better to get:
>>>
>>> Query query = Select(a).Where(id == 5);
>>
>> I think that's still awful. I prefer:
>> Query query = mixin(SQL("SELECT * FROM a WHERE id=5"));
>  >
> 
> Thanks for example - it talks to me more than 1000 words :-)
> 
> Your proposal is indeed interesting. (And I think it is what Dennis 
> Luehring was reffering to).
> 
> But I have to say it has some drawbacks. Let me enumerate them:
> 
> 1. Extending such a queries on runtime would be rather difficult IMHO, 
> and will not look very nice. With my solution you can do something like 
> this:
> ---
> Column cols = [person.name, person.surname, person.nick];
> for(i=0; i<rows; i++) {
>   InsertStatement insert = Insert();
>   foreach(Column col; cols) {
>     insert ~= insert.insert(col, getText(i, col));
>   }
>   db.execute(insert);
> }
> 
> * example not tested, but something like this is already possible in my 
> framework.
> 
> Constructing queries dynamically is very useful for creating e.g. 
> universal gui controls which could be just binded to database tables.
> 
> Another useful example is sending SQL expression (not the whole 
> statement) as an argument to function.
> 
> To make it work nicely with mixins IMHO you will have to make this kind 
> of SQL to look much uglier than in this simple case.
> 
> Do you have any proposals how it could look like with mixins?

There's nothing stopping you from using local variables in the mixin 
string. A simple possibility is to use $ for embedded variables. (You 
can avoid that, but it's much more difficult, and has some minor 
downsides, you can't have use a local variable called 'select', for 
example).
I pretty much got this working for BLADE, but the CTFE memory bug makes 
it completely unusable at present.

> 2. I see also problem with IDE-s which will have to be changed to 
> understand DLSs in mixins. I think that it is doable and even can be 
> done quite nice, but currently there is *no* support for such a feature. 
> It means that you will not have:
> 
> a. syntax highlighting
> b. no IDE proposing your names of variables and methods
> c. no refactoring

That's true, and indeed very difficult to solve.

> 3. Sometimes having more expressiveness in language can avoid creating 
> new DSLs. I think it is a Good Thing (tm). In fact I took that way and 
> decided to integrate SQL DSL language into mother language. That way 
> programmers don't have to learn new syntax, but just use existing syntax 
> of mother language to solve specific problems. Using DSL in mother 
> language resolves then into just writing special kind of API, which can 
> be used in standard way to achieve goal. D and most other languages from 
> C family are almost perfect candidates to make something like this with 
> SQL.
> 
> So while I can agree that original SQL looks much better than any kind 
> of its imitation, I think that it is not necessary better for productivity.

That's a worthwhile criticism of DSLs in general.