[alicebot-archcomm] <that> when

[Noel Bush]

> > 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>.
> 
> This seems quite a good solution. If a botmaster knows that 
> he encounters a
> loop in a category, he can change the value of that to 
> whatever he needs. It
> should be understood, that this change of "that" should only 
> be temporary,
> in the scope of processing one template (this includes all srais), but
> should not propagate to the 'calling category', nor affect the general
> dialog history (beforethat etc.).

One thing to notice about the skeletal example of a loop that I provided
is that it shows a situation in which some test determined that the
response should proceed differently.  That is, it is only in cases where
AIML doesn't supply some needed power that the usual match behavior
needs to be overridden.  This is worth thinking about.  Is it really
right to provide this ability to override <that> just to support the
general overriding of AIML's core functionality?

> The recent implementation by Jon Roewen uses a little 
> different approach.
> It's like a stack - the current value of <that> is pushed on the stack
> before a <srai> to prevent loops, and after the srai returns 
> the original
> value is popped.

This would definitely cause the vast majority of <that>-dependent AIML
to break, I think.  This may be a case where 'programmers designing
content tools', a problematic mentioned by Chris Fahey recently, exposes
problems.  Just consider the example mentioned in a previous post by
Rich -- the typical "yes" situation.  If <that> is popped onto a stack
before a srai, then all of these "synonyms" for "yes" become useless!
Maybe someone will alert Jonathan Roewen to this problem?