[alicebot-archcomm] <set> tag, and clearing predicates

ccallen alicebot-archcomm@list.alicebot.org
Tue, 10 Dec 2002 08:50:18 -0800


> For the next ProgramV release I'm working on a mechanism, that all used
variables - aka predicates - must be declared in the startup file (i.e.
predicates.xml):

> I believe Kim's ProgramP has a <forget/> tag to achieve the effect of
clearing all variables.

Making <set name="x"/> shorthand for <set name="x"><star/></set> and the
<clear> tag.

These examples are all implementation specific, one of the goals of the spec
is that it should allow for portability, so that an aiml file has a farily
good chance of running on different aiml interpreters with out too many
modifications. I plan to handle non-existant variables in yet another way,
but it would not make sense to drive my implementation into the spec as
well.

I agree with Ernest that these proposals do not need to be made part of the
spec. I do like the idea of being able to test for the existance of a
variable, although it would not make sense in Ernest's Program V.

What would be the difference in testing for an empty string in the case that
an undefined variable returned an empty string? You could not explicitly
test for an undefined predicate, but this would get around producing
sentences with gaps in them yet still be portable. Ernest would not be
concerned with returning an empty string, rather then a NULL because it the
parser should catch it. My interpreter could do it either way (empty string
or null).

I think my strongest argument for the exist test would be in testing and
regression testing (for the interpreter itself). Now that I am thinking of
it, I may put it in just to shave some time off the debugging cycles. I also
like the idea of making the existance a property of the predicate itself so
that you could say

<template>
var 1 [<get name="var1" return-type="exist">]
var 2 [<get name="var2" return-type="exist">]
</template>

This way I can quickly check to see that variables were added to the local /
global scope and track down regression bugs hopefully before the users do!

Conan

----- Original Message -----
From: "Ernest Lergon" <ernest@virtualitas.net>
To: <alicebot-archcomm@list.alicebot.org>
Sent: Tuesday, December 10, 2002 6:14 AM
Subject: Re: [alicebot-archcomm] <set> tag, and clearing predicates


>
> I do not understand, what Jonathan means with
>
> <set/> => <set><star/></set>   .
>
> Or just a typo? Varname missing? Should read:
>
> <set name="x"/> => <set name="x"><star/></set>  ?
>
> Anyway, I think too, that this is not wanted. We should leave the
> shortcuts as they are - to repeat the specs:
>
> <star/> => <star index="1"/>
> <sr/> => <srai><star/></srai>
> <person/> => <person><star/></person>
> <person2/> => <person2><star/></person2>
> <gender/> => <gender><star/></gender>
>
> And we don't need a special tag <clear>. The only change should be to
> allow the absence of content in <set>. So:
>
> <set name="x">y</set> => set the variable 'x' to the value 'y'
> <set name="x"/> => set the variable 'x' to the value '' (empty)
>
> This leads us to another problem: What means 'exists', 'defined',
> 'empty' or 'zero'?
>
> A variable 'x'
>
> - exists, if it is declared somewhere before the first use.
> - is undefined, if it exists, but has no value.
> - is defined, if it exists and has a value.
> - is empty, if it is defined, but has the value ''.
> - is zero, if it is defined, but has the value '0'.
>
> Another issue is the zero-but-defined-problem. In most cases accross all
> programming languages the values '' and '0' mean 'false', while any
> other value means 'true'. Moreover an existing value returns 'false', if
> it is undefined.
>
> While especially in Perl you can write elegant boolean expressions
> according to that rules, they throw you sometimes in semantic bugs hard
> to resolve.
>
> Therefore I'm against something like 'exists' in AIML - it might
> irritate more than help.
>
> Moreover we don't need an 'exists', if we make clear, how the wildcards
> are working. The specs allow simple-pattern-expressions in <condition>
> and <li>, so it should work like:
>
> <condition name="x">
> <li value="a">special value a</li>
> <li value="b">special value b</li>
> <li value="*">any value aka not empty</li>
> <li>default aka empty in this case</li>
> </condition>
>
> Or as 'if not empty then' statement:
>
> <condition name="x" value="*">
> variable x is not empty and has the value <get name="x"/>
> </condition>
>
> BTW: ProgramV behaves like this already.
>
> For the next ProgramV release I'm working on a mechanism, that all used
> variables - aka predicates - must be declared in the startup file (i.e.
> predicates.xml): The parser gives an error, if it finds a <get> or <set>
> with an unknown variable name. Moreover <condition> and <li> tags are
> checked in a similar way.
>
> This makes not only shure, that all variables exist but also eliminates
> possible typos in the variable names - a bug sometimes hard to find, if
> you wonder, why your cats don't work correct.
>
> Another issue to consider is, if we have declared a predicate with a
> default value:
>
> <predicate name="it" default="something" set-return="name"/>
>
> what happens if we do:
>
> <set name="it"/> resp. <set name="it"></set> ?
>
> What should <get name="it"/> return afterwards - the string 'something'
> again or just ''?
>
> And what should <condition name="it" value="*"> evaluate to? 'true' -
> because the string 'something' is returned, 'false' - because the actual
> value is '' ?
>
> Ernest
>
> --
>               ProgramV - Alice on Perl - available at
>                http://www.virtualitas.net/perl/aiml/
>
>       VIRTUALITAS - Manufacturer of fine OOPPS - since 1996
> *********************************************************************
> * VIRTUALITAS Inc.               *      http://www.virtualitas.net  *
> *                                *                                  *
> * European Consultant Office     *                                  *
> * Internationales Handelszentrum *                                  *
> * Friedrichstraße 95             *   contact:Ernest Lergon          *
> * 10117 Berlin / Germany         *    mailto:Ernest@virtualitas.net *
> *********************************************************************
>       PGP-Fingerprint 6E6F DC17 A886 342D  D63F 7880 12F5 6BA9
>         PGP-Key http://www.virtualitas.net/Ernest_Lergon.asc
>
> _______________________________________________
> alicebot-archcomm mailing list
> alicebot-archcomm@list.alicebot.org
> http://list.alicebot.org/mailman/listinfo/alicebot-archcomm
>