Short list with things to finish for D2

[Don]

Chad J wrote:
> Don wrote:
>> yigal chripun wrote:
>>> aarti_pl Wrote:
>>>
>>>> Walter Bright pisze:
>>>>> Don wrote:
>>>>>> There's not many sensible operators anyway. opPow is the only
>>>>>> missing one that's present in many other general-purpose languages.
>>>>>> The only other ones I think are remotely interesting are dot and
>>>>>> cross product.
>>>>> Yup.
>>>>>
>>>>>> Anything beyond that, you generally want a full DSL, probably with
>>>>>> different precendence and associativity rules. Eg, for regexp,
>>>>>> you'd want postfix * and + operators. There are examples of clever
>>>>>> things done in C++  with operator overloading, but I think that's
>>>>>> just because it's the only way to do DSLs in C++.
>>>>> I was enthralled with the way C++ did it for regex for a while, but
>>>>> when I think more about it, it's just too clever. I think it's more
>>>>> operator overloading abuse now.
>>>>>
>>>>>> I don't think the applications are there.
>>>>> I agree.
>>>> Well, I can understand your fear about operator abuse. And I agree
>>>> that code might be awful when operator overloading will be abused.
>>>>
>>>> But I have in mind one very convincing example. I defined in D/Java
>>>> SQL syntax. They are also other frameworks which do the same.
>>>>
>>>> What can I say about my experiences with using such framework: it is
>>>> very, very powerful concept. It cuts time necessary to develop
>>>> application, makes sql statements type safe and allows to pass around
>>>> parts of sql statements inside application. It also makes easy
>>>> refactoring of sql statement (especially in Java). Its huge win
>>>> comparing it to defining DSL as strings.
>>>>
>>>> It's hard to explain just in few sentences all details. I have
>>>> already done it long time ago, and in my first post I provided links.
>>>>
>>>> Problem with current approach is that I have to define SQL in D/Java
>>>> in following way:
>>>>
>>>> auto statement = Select(visitcars.name).Where(And(More(visitcards.id,
>>>> 100), Like(visitcards.surname, "A*")));
>>>>
>>>> Please look at code in Where(). It's so awfuuuuulllllll!
>>>>
>>>> It would be so much better to write:
>>>> auto statement = Select(visitcars.name).Where((visitcards.id `>` 100)
>>>> `AND` (visitcards.surname `Like` "A*"));
>>>>
>>>> I used here syntax which you have proposed with delimiter ``. I think
>>>> it is good enough solution for such purpose.
>>>>
>>>> But please, don't underestimate problem! Many DSL languages would
>>>> never appear if languages would be good enough.
>>>>
>>>> As I said solution with delimiter is good enough for me. It has
>>>> another advantage that it clearly shows in code that you have
>>>> overloaded operator here, so no surprises here. Additionally when you
>>>> implement template function:
>>>> opInfix('AND')(val0, val1);
>>>> you pass string into template. So I see it quite intuitive that you
>>>> use string as operator: ``. Maybe there will be not necessary to
>>>> change current behavior that `` defines string.
>>>>
>>>> I think we have good possibility to  open this door now. It can be
>>>> even implemented later, but I would wish just not to close this door
>>>> now :-)
>>>>
>>>> BR
>>>> Marcin Kuszczak
>>>> (aarti_pl)
>>> There's nothing more hideous than all those frameworks in Java/C++
>>> that try to re-enginer SQL into functions, templates, LINQ, whatever.
>>> SQL *is* a perfectly designed language for its purpose and it doesn't
>>> need to be redisnged! The only problem with this is the type-safety
>>> when embedding sql as string in a host language. the solution is
>>> two-phased:
>>> phase a is simple, look at the C# API for postgres (I think). The
>>> query is one string like:
>>> "select * from table where :a > 42", the :name is a place holder for
>>> the host-language variable, and you call an API to bind those :names
>>> to variables in a type-safe way. the downside is that it's verbose.  
>>> phase b is what Nemerle does with the above - it has an AST macro to
>>> wrap the above so you can write your query directly and it is checked
>>> as compile-time.
>>> No operators were abused in implementing this. 
>> I quite agree. What we can do already is:
>>
>> auto statement = db.execute!(`select $a from table where $b > 100 && $c
>> Like "A*"`)(visitcars.name,visitcars.id, visitcars.surname);
>>
>> which I personally like much better than the proposed goal:
>>
>>>> It would be so much better to write:
>>>> auto statement = Select(visitcars.name).Where((visitcards.id `>` 100)
>>>> `AND` (visitcards.surname `Like` "A*"));
>> (Replace $a with your preferred method for defining placeholder variables).
>>
>> And the question then is, can we improve the existing solution? And if
>> so, how? I just don't think the solution involves overloading operators.
>> I think this a great example of why we *don't* want arbitrary operator
>> overloading: there's no point overloading && and > if you can't make
>> 'from', 'where', and 'like' to all be infix operators, as well!
> 
> This sounds like a job for better mixin syntax.
> 
> So let "template#(args)" be equivalent to "mixin(template!(args))".
> 
> Then you can do
> 
> auto statement = db.execute#(`select $visitcars.name from table where
> $visitcars.id > 100 && $visitcars.surname Like "A*"`);

Yeah, something like that. Or it could mixin automatically. eg if
macro foo(args...)
foo(args) meant  mixin(foo(args)).

then the syntax would be:
db.execute(`select $visitcars.name from table where $visitcars.id > 100 
&& $visitcars.surname Like "A*"`);

which has advantages and disadvantages. So there's quite a bit of 
flexibility. A lot of potential for brainstorming!