I'm gathering that bschmer is feeding the commands to that interpreter, and the perl code should be able to make decisions on the RESULTS of those individual commands. (See the == FAIL case he illustrates.) Thus, the behavior or selection of later commands can be adjusted based on the results in earlier tests. Correct me if I'm wrong, but pre-authoring a more complicated script file ahead of time with a simple template tool won't help there.
--
[ e d @ h a l l e y . c c ]
This is my 1000th posting to PerlMonks.
| [reply]
[d/l] |
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"});
and then pre-load a per-interpreter module which provides functions (command1 etc) which must also already exist.
| [reply]
[d/l]
[select] |
