[alicebot-archcomm] <that> when
Richard Wallace
alicebot-archcomm@list.alicebot.org
Wed, 23 Jan 2002 15:38:34 -0500
I need more time to look into this problem. I believe that
some AIML in the A.L.I.C.E. brain would break if we changed
the behavior of <that/>.
Consider a simple YES pattern with <that>
<pattern>YES</pattern><that>CAN PIGS FLY</that>
If the client utters any synonym of YES, like
YUP, UH HUH, OF COURSE, AFFIRMATIVE, and so on,
then each of those categories (as written in A.L.I.C.E.)
will contain <srai>YES</srai>. We would want to
preserve the value of <that/> when we match
the category with <that>CAN PIGS FLY</that>
Conceivably, there could be a cascade of <srai>'s linking
a collection of synonyms to the same template, e.g.
YAH-->YEAH-->AFFIRMATIVE-->YES.
Rich
---------- Original Message ----------------------------------
From: "Noel Bush" <noel@alicebot.org>
Reply-To: alicebot-archcomm@list.alicebot.org
Date: Wed, 23 Jan 2002 07:37:35 +0300
>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
>
>_______________________________________________
>alicebot-archcomm mailing list
>alicebot-archcomm@list.alicebot.org
>http://list.alicebot.org/mailman/listinfo/alicebot-archcomm
>