As was pointed out in an old post I came across (Kinds of action - #3 by Ron_Newcomb), the internal structure of a “behavior” is just a routine returning a boolean/truth state. For example, given
Jumping is behaviorA.
Waving hands is behaviorA.
the I7 compiler produces something like
[ NAP_0 ;
if ((((action ==##Jump)))) rtrue;
if ((((action ==##WaveHands)))) rtrue;
rfalse;
];
The routine has no parameter, it just examines the action global used by the parser and templates – essentially inspecting a part of the current action. It’s not exactly the same type of thing as what’s produced for a definition, which is a routine that takes a parameter (of some type) and returns a truth state. I’m not sure how much functional difference that makes at the I7 level, though, because the compiler allows use of a behavior as an adjective on a stored action (e.g. if the current action is On-Task...). It seems that, when testing for applicability of a behavior, the generated code also looks at actor and/or act_requester at the point of checking NAP_0(), so the I6 routine by itself is not the whole story.
Note that using an adjective as shown is not really allowing nesting of behaviors, it’s just simulating that ability (sort of). I wouldn’t say that behaviors should categorically be avoided. Certainly use of behaviors would be easier to read and understand in the source code than a very complicated definition.
I can’t think of anything that is uniquely available only to behaviors, but if I do I’ll come back to post it. (And I encourage anyone else to chime in if they can think of one.)
A side note for the Mad Scientists’ Club: I’m noticing that in 6M62, it’s possible to define rules like
After behaviorA:
...
After an actor behaviorA:
...
but there doesn’t seem to be an equivalent capability to write one like
After someone behaviorA:
...