[alicebot-archcomm] <that> when

[Noel Bush]

Two intertwined questions have arisen several times in recent public
discussions:

1) Does the value of <that> change during a srai?
2) Should AIML allow the AIML author to change the value of <that> (as a
predicate with name "that")?

For better or for worse, Program D 4.1.4 currently works like this:

1) <that> does *not* change during a srai.
2) The AIML author *is* allowed to change the value of <that>.

I am not sure whether this is the way things ought to be, and I have
voiced opinions on all sides of all fences.  Here's what presently comes
to mind:

1) PROS of changing <that> during a srai:

a. It becomes possible to "escape" from loops like this:

<category>
  <pattern>*</pattern>
  <that>SOMETHING SAID BEFORE</that>
  <template>
    <!--Some test or another-->
    <condition name="testResult">
      <li value="oneResult"><srai>the next thing</srai></li>
      <li><sr/></li>
    </condition>
  </template>
</category>

This may look strange, but it does fit a kind of case that needs to be
handled sometimes.  For whatever reason, some condition needs to be
checked after matching, and if the condition isn't met, then the match
should be tried again, but this time not in quite the same context.

I am not so comfortable with that scenario, but I think this is the kind
of thing people have run into.

Can anyone think of more PROS?

CONS of changing <that> during a srai:

a. The obvious question is: to what should <that> change?  Should it
become empty?  Should it get a default value?  Should it get the value
of whatever the bot response is so far, even if that response has not
yet been passed to the user?  Should it be changeable by the AIML
author?  If changeable by the AIML author, what takes precedence -- the
automatic value or some set operation (which may happen at a number of
different points)?

b. Whatever the case, if <that> will change it means that writing AIML
becomes more difficult in general, because you now cannot guarantee that
<that> will always match what the bot previously said to the user.
Whatever you know it *might* match, you cannot have that certainty.

2) PROS of allowing the AIML author to change the value of <that> (in
general):

a. The particular situation above can be avoided simply by doing a
	<set name="that"></set>
   just before the <sr/>.  One can think of this as a "forget what I
just said" move.

b. There is a general point of view that any extra degree of "control"
is good.  (One may counter by saying that the more "controls" there are
(really variables), the less predictable becomes the system.)

CONS of allowing the AIML author to change the value of <that> (in
general):

a. The predictability problem mentioned above is the same.

b. The original meaning of <that> gets left in the dust.  One might as
well not say that <that> really has anything to do with context at all
anymore, if its value can be manipulated at any time.  It just becomes a
kind of special index always hovering within easy reach.

I guess you can see where I lean: I lean toward cancelling the present
(accidental but interesting) capability in Program D to manipulate
<that>, and toward specifying clearly that <that> does *not* change
during a srai.

Where would that leave AIML authors who feel they need this kind of
flexibility?

Well, if anyone will take up this discussion, I feel it would be helpful
to present some challenge cases, illustrating the need for either or
both of these items.  We can all take a look at the alternatives and see
what's prettier, what's preferable.

Noel