hmm, but then we lose out on embedding within C.
IMHO we can bikeshed for the name later :D

I have been thinking a bit about grammar for writing the DSL.
We can build LL(1) parser for it (no need to make it powerful i suppose since DSL's mostly have simple syntax).

My main concern is how do users expect our toolkit to be ?
They have their API, and now they want to write a DSL using our tool.

If i were a user, I would expect to write the DSL spec in a BNF-like notation and provide equivalent C or C++ code
in "semantic action" for the lowering.

for instance, suppose I have a graphics lib which uses following sequence to draw a red line:

struct line *l = create_line ();
set_color (l, COLOR_RED);
draw_line (l);

Instead I want to do it with following DSL stmt:
draw red line;

So I would expect to be able to express "draw red line" in BNF notation,
and me to provide the lowering:
SOmething like:

%line_nonterminal<struct line *>: "draw" "red" "line"

{  // starts a semantic action
   $$ = create_line ();
   set_color ($$, COLOR_RED);
   draw_line ($$);
}

%queryfunc = DRAWFOO

and I use the DSL in following C code:

#include "graphics.h"

int main (void)
{
  DRAWFOO("draw red line");
  return 0;
}

Our clang plugin would be given the above c code and the grammar description (i don't know how it can find the grammar description but let's leave that aside for moment).
The tool would then do the following:

a) Create parser for the grammar on the fly.
b) Look for the queryfunc string, and parse it using our built parser.
c) if a production matches, then replace the queryfunc (string) with the AST form of C code present in semantic actions.

Alternatively we could also compile down to plain C by replacing the queryfunc(string) with the corresponding C code in the actions.

For instance instead of plugin, we will have a clang tool that will take above code as input and produce following c code as output: