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

[Nick Sabalausky]

"Aarti_pl" <aarti at interia.pl> wrote in message 
news:gepf4o$1118$1 at digitalmars.com...
> 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)

If we had extension methods, you could change:

.Where(EqualsOrMore(people.age, 20))

to:

.Where(people.age.EqualsOrMore(20))

Which is a little bit nicer. But I agree, a way to return a non-standard 
type from an operator overload would be even better.

Something about both of those above reminds me of a unittesting tool I was 
looking at a while ago...can't remember what it was though...I *think* it 
was a unittesting tool...