SUB my_func
    COMMAND1
    COMMAND2
ENDSUB
CALL my_func
[download]

Oh, macros. How, exactly, is this easier for them to learn to do than the following:

sub my_func {
   command1;
   command2;
}
my_func;
[download]

In your case, they're learning a very simple language; in my case they're learning a very simple language that just happens to be an extremely limited subset of Perl but is not fundamentally more complicated than the language you want to teach them. (The syntax is very marginally more involved (mainly, the need for semicolons between commands), but there are no extra concepts at all.)

They only have to learn the bare minimum they want to use. If they don't want to call macros with arguments, then they don't need to be able to write macros that take arguments, then they don't have to know about @_. If they don't need to maintain state either (apart from state your procedures maintain automagically, like the current web page or whatever), then they don't have to know about variables either (much less hashes, references, and so on). They don't need to learn about control flow unless they start asking things like, "How can I make this happen twenty times in a row, without just copy and pasting it twenty times?" or "How can I make something only happen under certain circumstances". As long as they're content to stick to a strictly procedural paradigm, they don't need to know about return values, context, list transformations, or a a whole mess of other things that an actual Perl programmer would need to know.

So far, I've only introduced them to two Perl builtins (include and sub), and one of those only because they (err, you) asked for the ability to write macros. They don't need to know ANY other Perl keywords, unless they start asking things like, "How can I output a message to the person running the test script, to tell them what it's about to test?". If they did that, I'd teach them to write print "Message Text Here";, but they wouldn't need to know anything else about the print operator (for example, that it's an operator, or that it operates on a list, or that it flattens the list and evaluates the arguments in string context, or that it can optionally take a filehandle, or what it returns, or any of the other stuff you'd learn about print if you were actually learning Perl, which they're not).

An advantage of my approach is that if they do ask for certain more advanced capabilities, you don't have to extend your language; all you have to do is show them the feature they're asking for. Plus, it saves you from needing to write a parser. I don't think it's worth inventing a language and writing a parser just to avoid the need for semicolons between commands.

If they want to learn to write functions (i.e., subroutines that return meaningful values, as opposed to procedures or macros, which are executed only for their side-effects), there are, irrespective of what language and syntax you teach them, some extra concepts that they would have to learn. Even macros are a concept, but not so advanced a concept as functions. (Though, when you start wanting to pass arguments to your macros, you probably need variables, which puts you almost halfway to what you need for functions. But these QA people don't want to learn Perl, so they are probably not going to be wanting to write macros that take args in the immediate future, much less functions that return values. That smacks almost of being borderline on real programming. Throw in conditionals and it might even be Turing-complete.)

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]

Everything you've said is absolutely correct. In fact, it's probably easier to code (initially) than what I've proposed, and might even be less buggy, too.

Except, I don't want to use eval or do. You're missing the fact that this is a QA application. QA applications have to be as locked down as possible. They have to be as provably correct as possible. I know I've been bitten by tests that were false positives or false negatives, due to mistakes in the test or (worse!) the testing harness.

As for Turing-completeness, I might be wrong, but I believe that GOTO, JZ, and JNZ are the minimal requirements for Turing completeness, all of which I've already provided for in earlier posts.

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Except, I don't want to use eval or do. You're missing the fact that this is a QA application.

Well, if you reread the original post at the top of the thread, it is QA people who will be using this. They aren't programmers, but presumably they know how to do QA. If not, the company has problems that inventing a scripting language won't solve.

As for Turing-completeness, I might be wrong, but I believe that GOTO, JZ, and JNZ are the minimal requirements for Turing completeness

It depends. Turing-completeness is about equivalence, not a specific implementation. Unlambda is Turing complete but does not provide GOTO or anything like it, really. (All the work in Unlambda is done by combining and applying functions.) Pascal does not provide GOTO and is certainly Turing complete. I don't think Befunge provides GOTO; it handles control flow by changing directions, not positions. Hofstadter argues convincingly that sufficiently powerful formal systems in math (e.g., Typographical Number Theory or Principia Mathematica) are Turing-equivalent.update: No, wait, that's not right. TNT represents all primitive recursive truths, but not all general recursive truths. I was momentarily confused. P.M. is probably similar. It is, however, almost certainly possible to construct a Turing equivalent formal system.

Also, I do not see why both JZ and JNZ should be required; they are, as near as I can determine, equivalent; at _least_ they are equivalent if you also have GOTO, because a JNZ followed by a GOTO is equivalent to a JZ, and a JZ followed by a GOTO is equivalent to a JNZ. However, a decision mechanism of some kind (what I called "conditionals") is needed. JZ and JNZ can provide this. In Perl we use (among other things) if. I suspect, however, that conditionals are a feature the QA people in question (who don't want to learn Perl) won't need, at least, not initially. All they really want to do, as I understand it, is call a series of prefabricated procedures that the OP is going to write.

---

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]