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)
