[alicebot-archcomm] Predefine predicates/properties

Ernest Lergon alicebot-archcomm@list.alicebot.org
Tue, 29 Jul 2003 14:42:09 +0200


Jonathan Roewen wrote:
>> Ernest Lergon wrote:
>> Proposal:
>>
>>    The AIML interpreter must raise a fatal error at load-time, if a
>>    predicate/property is not predefined.
>>    The content of the attribute 'name' is case-sensitive.
> 
> [snip] It's like the variable declaration rules of C,
> where you must declare everything before you use it. Ie, can't declare a
> variable in a for loop statement, whereas in C++ you can declare a variable
> anywhere you want, and not even initialise it if you don't want to.
> 
> [snip] Your references to AIML sets referring to predicates that
> aren't initialised is the AIML writer's fault.
> 
> [snip] IE:  <get name="name">user</get> would produce "user" iff the predicate
> results in "" (empty string), otherwise it would be the value of the
> predicate (eg "bob").
> 
This is exactly, what the predefinition does:
    <predicate name="name" default="user" set-return="value"/>

I find it confusing having a get-element *with* content.

It's extremely helpful to have a strict variable handling, even in
weakly typed languages - that's why I prefer Perl over PHP.

But your argument about declaring variables on-the-fly has to be
considered - so let's refine the proposal.

In respect to the standard using of variables in programming languages -
aka a variable is only visible in the block it is declared in - we could
state:

1) A property asccessed by <bot> must be predefined in the startup
    section.
    It is visible to all categories and is read-only.

2) A global predicate accessed by <get>, <condition> or <li> must be
    predefined in the startup section.
    It is visible to all categories and is writable by <set>.

3) A local predicate accessed by <get>, <condition> or <li> must be
    predefined by <set> before using.
    It is visible only to the category it is declared in and is only
    writable here by <set>.

    The AIML interpreter must raise a fatal error at load-time, if a
    predicate/property is not predefined in the named way.
    The content of the attribute 'name' is case-sensitive.

1) is selfevidently.

E.g. for 2) and 3) (pseudo AIML):

<aiml>...<startup>...<bot>...<predicates>...
    <predicate name="name" default="user" set-return="value"/>
</predicates>...</bot>...</startup>...</aiml>

<aiml>...

<templ>
  Your name is <get name="name"/>.                <!-- Ok, predefined -->
  Your birthday is <get name="birthday"/>. <!-- Error, not predefined -->
  <think>
    <set name="age"><star/></set>               <!-- Ok, local define -->
  </think>
  Your age is <get name="age"/>.                <!-- Ok, local access -->
</templ>

<templ>
  Your name is <set name="name"><star/><set>.     <!-- Ok, predefined -->
  Your age is <get name="age"/>.           <!-- Error, not predefined -->
</templ>

...</aiml>

Local predicates are useful in conjunction with <condition> like here:

<think><set name="temp"><star/></set></think>
<condition name="temp">
   <li value="...
...

Local predicates can always be handed over to another category without
the need of global declaring:

<think>
   <set name="temp"><star/></set>
   ... process/change predicate 'temp' ...
</think>
<srai>Call another category with <get name="temp"/></srai>

A performance hint: The used internal data format and its processing at
run-time should be optimized in respect to fast access, so the syntax
and error checks of the AIML files have to be done at load-time, which
is not mission critical. This holds for the "compiled" data format used
by ProgramV as well as for storing categories in a database like by
ProgramE. Once stored, the templates are just "executed" without any checks.

I think, one part of the pragma "Keep AIML simple" is to provide
mechanisms helping AIML writers to avoid faults.

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 *
* Ernest Lergon                  *    mailto:Ernest@virtualitas.net *
*********************************************************************
       PGP-Fingerprint 6E6F DC17 A886 342D  D63F 7880 12F5 6BA9
         PGP-Key http://www.virtualitas.net/Ernest_Lergon.asc

---------------------------------------------------------------------
SPAM ALERT                       http://www.virtualitas.net/spam.html
---------------------------------------------------------------------