[alicebot-archcomm] <that> when

[Jon Baer]

Here are my viewpoints on it:

Ive always felt like there should be *some* kind of <break>ing ability for a
number of things, like conditioning for example.  I think if you took SRAI
as a form of conditioning you get the same problem, in that there is no way
to say "hey stop everything and send the content we have already back to the
user", I think only because some parsing might not work like this (or it
might, Im not sure).

I think we are floating away from the context idea then if we do treat
"that" very special, which I'd hate to do, it has a very specific meaning,
the last sentence that came from the bot explicitly externally, not
internally.

I think the only one major reasons I might be against it is because of
current work relating to real-time editor viewing.  For example Im trying to
work on this editor where if I type I then LIKE then ICE then CREAM, I can
see the process happen in realtime for what my results would be in the GUI,
but if I decide to hit BACKSPACE and edit the input, my vales do change and
"that" has to be taken into consideration.  So if an SRAI is changing the
parameter while the typing is going on, the results would be wierd I'd
think.

All in all I think SRAI should be straight forward without <that> being
evaluated, however, I'd hope that maybe you might consider *extending*
<srai> in the future so that maybe it could be evaluated that way.  <srai
consider="that"> ;-)

- Jon

Noel Bush wrote:

> 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