Short list with things to finish for D2

[Don]

aarti_pl wrote:
> Don pisze:
>>
>>> Additionally in my framework you can pass around parts of SQL e.g. :
>>> WhereExpression exp = Where(More(visitcards.id, 100));
>>>
>>> You basically *CAN NOT* do it when just using strings. 
>>
>> Of course you can define a where clause using strings.
>> (I'm not sure when you'd want to, though. I suspect that the fact that 
>> you can do it in your framework, is an implementation detail rather 
>> than a design goal. It's easy to think of uses for run-time generated 
>> naked WHERE clauses, but much harder for compile-time ones).
> 
> 
> Not exactly. At least it was not the case last time we talked about it:
> 
> *I will give here only NG post numbers*
> 
> 79272 Domain Specific Languages in D; was: C++, D: Dinosaurs?
> 81026 Operator overloading
> 81078
> 81393
> 
> And you finally agreed with me that it is not possible. So I take it 
> proven :-)
> 81424


I believe I was agreeing that it wasn't possible to do it with a single 
SQL ctfe function.


> 
> Possibility to split whole SQL statement into parts is useful. You can 
> mix & match these parts together as you want. It is similar as you want 
> to split you big chunk of code into smaller parts. You can for example 
> make separate expressions objects and then put them one by one into 
> Where().
> 
>> `AND` is not operator overloading in the traditional sense. This is 
>> something else. You're proposing a whole new infix notation, and it's 
>> difficult to evaluate it without knowing how it would work.
> 
> Well, with Andrei's proposition it is obvious for me that it should be 
> generalized. I stated it already in: 81392 (almost one year ago)
> 
> I will cite part of this e-mail:
> 
> *<citation>*
> Exactly. My first thoughts was to allow defining infix 
> keywords/operators in a similar way as today we can define prefix 
> operators:
> myFunc a b
> 
> or just:
> myFunc(a, b);
> 
> Why? Because they are use cases where infix notation is much, much more 
> natural than prefix notation.
> 
> So we still need:
> 
> 1. a myFunc b    - infix operator
> 2. a b myFunc    - postfix operator
> *</citation>*
> 
> After reading my old e-mail it seems that it can be further generalized:
> prefix(tuple_args)
> (tuple_args)postfix
> (tuple_args)infix(tuple_args)
> 
> Ok. Just a thought :-)

To quote something I said in that last post:

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


> Some more about more precise definition of this feature (proposals, to 
> think about it):
> 1. I don't agree that it is something different than traditional 
> operator overloading. It is just generalization.
> 2. After including Andrei's proposal the biggest part of this feature 
> will be already in language.
> 3. The only think to define is just how the caller side should like:
> a. Always demand `` when using operator overloading; (Pros: no abuse of 
> operators - you always know when operator overloading is involved; Cons: 
> doesn't look so good, especially in cases where you would expect plain 
> symbols)
> b. Don't demand `` in case of some standard operators like <>+-*/ etc. 
> In other cases demand ``(Pros: Looks better; Cons: you will not always 
> know that operator overloading is involved)
> c. Demand `` always when there is standard operator defined or operator 
> is not symbol, but identifier.
> d. Don't allow redefinition of same operator
> 
> Above concepts must be discussed, but it seems that there is not enough 
> courage in NG to change current situation.

Please. It's been very clearly stated, long ago, that : MACROS ARE 
DEFERRED TO D3.

> Well it's strange that the feature is called 'operator overloading' - 
> it's quite obvious that it's about defining some special functions. And 
> IMHO some other languages got it right.

IMHO, equating 'operator overloading' with special functions is a 
colossal mistake. I'm convinced that C++ got it badly wrong.

>> And I still don't think it looks terribly good for SQL. With:
>> id `>` 100
>> users would always be thinking, "why can't I just write id > 100 ? 
>> That ` is so annoying!"
> 
> Please believe me: it's 3000 times better than current situation. 

I don't disagree with that. I just think we should aim higher.