+1 and I should probably delay responding to avoid starting.convos that should be on the split ones … But I’ll just try to be brief instead 
I think the point was that the MLIR snippet starts inside a C++ program and so we’d need to extract it before the C++ program compilation.
Quasiquoting’esque form 
(I would say that C++ doesn’t have good support for it and then someone will come up with a constexpr parser as a counter of it being feasible …). So invoking the parser on it to construct the IR and using bindings to specify inputs and bind outputs? (E.g., attach’s first arg becomes arg0 in the IR snippet, or perhaps all snippets have to start with block, and explicit return that populates a vector). So making it a runtimes construct?
If we called builder b then b.create<AddIOp>(iter, iter) would work today, but to get to std.addiop(iter, iter) the insertion point would need to be in scope. Would the idea be that we have a vector of insertion points (to enter/exit scopes) and the top insertion point is used? So 10 characters saved but we need to add a std builder? [And I could have a macro B(AddIOp)(iter, iter) which might be terrible but also concise and doesn’t require much 
]
I think the helpers for loops/regions are clear wins and not too invasive (the lambda could always take a builder as first input and then the loop construct provides the correct one for the region).