No, you're right. But I don't see how the problem as posed makes sense since he wants to add syntactic constructs (e.g. close brace }) at runtime (i.e. post-parse).

So I'd guess I'd solve his specific problem by adding some plugin capability to his interpreters, so I could do something like MYEMPLOYER_APP_PLUGINS=Foo,Bar and then the Foo and Bar plugins get called at various stages of command and argument processing.

This would require defining an API for the plugins in terms of what they could inspect and what they could change.

So this is work. And hence sucks, and this is why little languages (DSLs) suck unless they are embedded within a more powerful general purpose language (so you can escape to the big language when you need to). Otherwise you find yourself re-inventing loops, conditionals, I/O etc in your little language over time.

So I guess really I'd write a converter to make all of these cmd files become perl and then just embed perl. It could be fairly mechanical (he already has the parsers):

command1({param1 => "value1", param2 => "value2"});
[download]

and then pre-load a per-interpreter module which provides functions (command1 etc) which must also already exist.