sub-routines re-visited

[JonC]

There has been a previous discussion of this topic here that referred to Verbot 4.
From what I have been able to deduce, the change to Verbot 5 has brought about a small change in how 'subroutines' seem to work.
(You will note that I am being equivocal here. All I can claim is that this is how my desk-top PC based Verbot 5 works!)

To recap first:
The way that a "subroutine" works is that you define a <send ...> command to send the Verbot to the subroutine. this is the equivalent of (part of) a "gosub" programming command.
The subroutine rule is part of the "root" rule list (ie it is not within a tree structure).
However, the Verbot cannot "return" unaided. To overcome this, before using the <send ...> command we set up a command to tell the Verbot which rule to go to.
I define this command in a vars-variable that I call "sender" either by using <mem.set sender ...>,
or the c# equivalent: <?csharp vars["sender"] = "..."; ?>
The contents of [sender] will be one or more <send ...> commands themselves that gets the Verbot back to where you want it.
Thus the full command might look like this: <mem.set sender <send A> <sendb>> )
or in c#: <?csharp vars["sender"] = "<send a> <send b>"; ?>

Okay: so now the Verbot knows where to go by one send command and it also "knows" where to come back to by the contents of [sender].
We can then send the Verbot of to the "subroutine" code quite happily
the last part of this "trick" is to write a rule as part of the subroutine that actions the contents of [sender]
For obvious reasons I always call this rule "return". I also prefer to write it in c#:
<?csharp Console.WriteLine(vars["sender"]); ?> though it can also be written as simply [sender].

Now: there are two ways of using the send commands:
By defining the rule you want the Verbot to return to as a child-rule of the return-rule you only need 1 send command "inside" [sender].
However, this can have the drawback that a mislabelled rule can have unintended and erratic consequences.
Alternatively you can concatenate <send ... > commands in [sender] (as indicated above) to return to where you want to go via a root-rule. This has the advantage that you do not need to specify the root-rule as a child-rule (you just need distinctively named root rules instead).
Where the Verbot4-Verbot5 difference seems to lie is that whereas in Verbot4 the Verbot would speak the outputs to rules within [sender], in Verbot5 this does not appear to happen.
For this reason the latter method is now preferable, imho.

[Mitch38]

Yes JC, that works perfectly. A robot that was built entirely on your principle is here: http://www.a-i.com/alan/handlers/oneliners.handler

That is just ONE of it's 'subroutines', but that robot has at least 50 of these. Folow the blue links and you can unravel the 'code'.

M
_________________
Don't worry, it will all be over soon...

[JonC]

With regard to Alan, all I can say is GULP !

Well, I've never claimed originality, but still...

Another little "wrinkle" with this idea is as follows:
Suppose you have a root-rule for a tree called "CarMakes".
I also write a second root-rule called "CarMakesPortal" (the name isn't important, but the function may be).
This rule's only input is its rule-name (so you'll never say it to the Verbot!).
CarMakesPortal 's ONLY output is <> (which is silence).
However, CarMakesPortal has as child rules ALL the rules you wish to return to for the tree "CarMakes".
Thus you can get back to ANY rule within the CarMakes tree with just a double-send set up in [sender]
<send CarMakesPortal> <send ...>:

The real advantage with this is that the return rules for your subroutines do not have to have all the return rules as child-rules. Indeed, given that the first <send ...> is to a root-rule, the return-rules need no specified child rules at all.
The real advantage with this is it means that you can set the return child rules for each tree independantly of every other tree.

To put it in terms of "Alan":
with this technique, if we had a sub-routine used by all 50 trees I could program (well, probably not - but you take the point!) each tree quite separately (complete with all return-points) and once confident that it worked, integrate the trees one-by-one without needing to set any more child rules.

Since I tend to build my kb in a 'modular' manner, this is a real time (not to mention temper!) saver.

[Mitch38]

I used it like this: You can use the subroutine to set up a CHAIN of trees, goto tree xxx then goto tree yyy. Simply return to wherever you'd like. I made a silly example:

Subroutine rule name: Magicword (that is it's only input, it's 'root name').

Output: You forgot to say the magic word.

Child1 input: please*
Child1 output: Thank you. [sender:]

Child2 is a simple trap, with a virtual child feeding back on the parent.

Child2 input: *
Child2 output: That is not the magic word. Try again.

I can call this from anywhere now, like this:

<send magicword><mem.set sender <send xxx>>

xxx is the root rule name you want to dump into after the person says 'please'. It dosen't have to return to where it started from. Perhaps I'm just re-discovering what you already know.

Thanks again, JC.
_________________
Don't worry, it will all be over soon...

[JonC]

Quite right Mitch, you can in fact 'return' to anywhere you want, depending on how you set up "sender".
You've actually pointed out another "trick" with the system that is useful, with the proviso that you are dealing with root-rules (primary rules as the editor calls them).
I'm glad you pointed that out: that you don't need to set virtual child rules if you are "returning" to the primary rule list.

[JonC]

Another (obvious) point that I thought I'd mention for the sake of completeness:

You can also use this technique within a "tree" structure.
In this version you do set child rules, but it is only a single send.
e.g. I have a chunk of code that I call from 2 places within one tree. By using <mem.set sender <send ...>> I can set the rule to return to before I <send...> to the code block which terminates with [sender].

[Mitch38]

So JC, When do we get to test this project of yours?
_________________
Don't worry, it will all be over soon...

[JonC]

When it is done