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

Ernest Lergon alicebot-archcomm@list.alicebot.org
Tue, 10 Dec 2002 15:14:30 +0100


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