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

[Julio César Carrascal Urquijo]

Hello Aarti_pl,

> Yes, something like this would be possible. But it would start to be
> very complicated, unmanageable and not so useful soon. Implementing it
> in such a way for every DSL will be very hard.

Fragment objects are used in SubSonic so I think it is manageable at least 
for the SQL case.

One thing I should probably have shown in the example is that Fragment objects 
just route calls to the underlying Query object so they are small and don't 
have any logic:

class WhereFragment
{
    this(Query query) { m_query = query; }

    OrderByFragment OrderBy(Column[] columns) 
    { 
        m_query.OrderBy(columns);
    }

    Query m_query;
}

In your case it would be a template of the Table class, of course. Also, 
you would need create a small number of them (WhereFragment, OrderByFragment, 
SelectFragment).


> Also there are cases in
> normal programs where it would be useful to have such checks.

Agree. For example, GUI controls sometimes requires you to set several properties 
to specific values to get a specific effect. This could benefit from having 
this kind of support from the language. Though I don't think this is a pressing 
issue.


> Currently I use simple runtime checks (somewhat simplified,
> pseudocodish and not tested code below):
> 
> class SelectStatement {
> string[] next;
> this() {
> next = ["Where", "From"]; //All possible options after
> construction
> }
> public SelectStatement Where(SqlExpression exp) {
> if ("Where" !in next) throw Exception("Syntax error");
> ...
> 
> next = ["OrderBy"];
> }
> }
> Probably it should be possible to implement something similar in
> compiler to make checks on compile time. If some variable has assigned
> object of such a class compiler should trace this variable and check
> if methods are called properly (in order, that they *are* called etc.)

I would say that fragment objects are simpler than littering your methods 
with these checks.



>> You should probably do as LINQ to SQL and start the query with the
>> FROM statement instead. That way you can cascade the type and help
>> auto-complete in IDEs.
>> 
> Well, I don't see problem here with my approach... SQL has a lot of
> options after SELECT keyword and before WHERE. How can I use them
> using only From?

I meant something like this:

auto q = From(Employee)
    .Where(Employee.Email, Is.EqualTo("jcarrascal at gm..."))
    .Select(Employee.ID);

This way the Employee type in the From() would cascade to the Where() and 
the Select() and you could add compile time checks to allow only columns 
of that table to be used in there.

One question: Do you library supports (inner/outer) Joins or have plans to 
support them?

Thanks