Domain Specific Languages in D; was: C++, D: Dinosaurs?

[Aarti_pl]

Nick Sabalausky pisze:
 > "Piotrek" <starpit at tlen.pl> wrote in message
 > news:geo14c$ol9$1 at digitalmars.com...
 >> Nick Sabalausky wrote:
 >>> [...]The concept of domain-specific languages is ultra-trendy these 
days
 >>> (probably promoted by the same knuckleheads that hailed things like
 >>> pure-OO, pure-functional, and Extreme Programming as silver 
bullets). But
 >>> I consider domain-specific languages to be purely a symptom of a 
strong
 >>> need for a better general purpose language.
 >>>
 >> Totally agree. At my point of view it looks excacly the same. I started
 >> with pascal then moved to c/c++ at university but I abandoned it 
because
 >> of its ugliness and non intuitive application development. Then I found
 >> working with PHP/JAVA much easier but I was disappointed by its
 >> fundamentals (please let me forget about PHP as a programming 
language).
 >> And when I was left without any hope I saw a Bright light. :D
 >>

(....)

 > I agree. I'd much rather just use a sensible API (DBMS-agnostic of 
course).
 > Pasting together SQL snippets is just plain ugly, and why dynamically
 > generate code just for the DBMS to go and parse it? I mean, geez, 
just cut
 > the middleman and pass the request directly. LINQ is better, but I'm 
still
 > not convinced it's the right approach. TSQL stored procedures are 
something
 > I'd rather, well, just write in a more "normal" language.  And then, of
 > course, there's the bizarre "insert" vs. "update" syntax 
inconsistencies and
 > general incompatibilities across vendors (ex: insert a row and 
retreive the
 > auto-gen id <- which is really a rather common thing to need to do,
 > particularly if you've got any foreign keys in the DB design, which 
again is
 > rather common).
 >
 > To be fair though, I have to say that without some of the advanced 
features
 > we've been starting to see in languages like D, C#, Python and Ruby, 
using
 > an API for any non-trivial queries could potentially get ugly.
 >

Above subject is very interesting. I didn't know for example about LINQ, 
but have very similar idea to implement Sql queries as specific objects, 
which are later executed.

Currently I implement something similar what is already working, and I 
have to say, it is working very good. My implementation right now is in 
Java (because of easy way to make refactorings with Eclipse), but I want 
to port it into D, and put into my libraries at DSource (Doost project).

For example LINQ statement:
------------------------------
var query1 = from p in people
              where p.Age > 20
              orderby p.Age descending;

------------------------------
will look in my implementation like below:

------------------------------
auto query = Select(people)
		.Where(EqualsOrMore(people.age, 20))
		.OrderBy(people.age, DESC)
		.OrderBy(people.name, ASC);
------------------------------

So it's quite similar to SQL standard, but without drawbacks of building 
SQL's as strings.

------------------------------

As I said before, my implementation is already working. But still I see 
many problems in OO languages (Java, C++, D) which disallows to define 
such sublanguage in a clear way.

Let me enumerate a few:

1. Lack of opImplicitCast()

I see this part as very important and blocking nicer solutions in many 
areas. Hopefully D will get it implemented sooner than later.

For example Where clause in SQL is defined as following:
Where(expression)

expression can be e.g. equality, column or select statement, so there is 
need to put all this cases when defining method "Where". With 
opImplicitCastTo() it would be possible to define it in e.g. Column. 
Then Where will take only objects of Expression. So we get better 
encapsulation.

opImplicitCast would also solve problems with slicing utf8 char arrays, 
as it would be possible to write class/struct with opImplicitCast which 
will convert to char arrays, keeping high level slicing in class/struct.

2. Lack of finer control over operators overloading

Current D implementation makes it impossible to use operators in SQL OO 
sublanguage. Although there is opEquals and opCmp you can not really use 
them as using them you can not distinguish what exactly operation was 
requested and you can not return different type than predefined e.g. 
bool in case of opEquals.

Above have of course its merits, but also disallows to define nice 
looking SQL queries.

To solve this problem I would suggest to allow definition of additional 
operators like below:
opRawEquals
(opRawNotEquals ??)
opRawMore
opRawLess
etc.

then only one: opEquals or opRawEquals can be defined.

It would be also nice to have possibility to define user operators, as 
it seems that it is natural for humans to use some operators in their 
infix form.

3. Impossibility to statically control meta language contructs.

Sql has its own syntax rules and currently they can not be enforced on 
compile time.

E.g. in select statement you would expect to have OrderBy after Where, 
not other way. Currently I can enforce order of clauses only on runtime, 
although it should be probably doable to enforce it on compile time. 
Currently it is also not possible to enforce that e.g. some method must 
be called:

Query query = Select(id).From(table);

Imagine that you want to enforce that in above query From() must be 
always called (Select is an object, From is method on this object).

So what's more is lacking in D, to absorb even more DSL languages?
Thoughts?

PS. If someone is interested in above subject and wants to help in 
porting project from Java and improving it - please contact me on my 
e-mail address.

Regards
Marcin Kuszczak
(aarti_pl)