[alicebot-archcomm] Predefine predicates/properties

[Jonathan Roewen]

> Local variables are very important when one considers recursion.  A
category
> has scope as defined by <srai>. The archcomm group discussed this
adjustment
> previously to correct the standards to reflect the effects of recursion in
> category processing.

Ah, recursion with <srai/> .. the only application I didn't consider, but
only because I never use predicates for a recursive definition .. for this,
I use wildcards, and then a predicate called temp if it needs modification
later.

The reason for this approach is simply because wildcards can't get
overwritten, and retain their values after an <srai/>, which makes them
extremely powerful from a programming perspective.

> What I don't understand is why boiling down AIML to arcane strict syntax
is
> any better than using simple terms for common expressions.  Ok, <sr/> is a
> shortcut for something else.  Isn't <input/> or <that/> a shortcut now
too?
> Just because extensions have been added to the tags doesn't dictate that
the
> clearer and simplier terms must be depreciated.

<input/> is not a shortcut. <input/> is not necessarily the same as <get
name="input"/>, and the same applies to <that/>.

In J-Alice, the input and that values retrieved by <input/> and <that/> are
stored in a separate repository than for normal predicates (<set/> &
<get/>). In fact, <that/> != <get name="that"/> at all in our
implementation. In fact, the specification does not state that these are at
all related, and should not be.

> For example, can't we add some simple means of handling agendas or
> emphasizing attention such as moods and goals.  What about ways of
> collecting categories into preferred processing of immediate reaction
verses
> delayed or background processing such as imagination and simulation.

I'm sure you can do that already .. Dirk has often posted lots of samples of
designing frameworks to cope with various types of systems.

> What about structuring of AIML to make editing it more modular (maybe like
> an subject orientated knowledge clustering like the original AIML category
> sets of ALICE 2000 and prior)?

You can still do that .. I'm guessing that for editing purposes, it was
probably easier to find the categories by ordering them by the first token
of the pattern. However, if a suitable editor, like ProgramN is no doubt
becoming, would make the old style maintainable. Which file contains an AIML
category doesn't affect the category itself or how it's matched.

> Anyway, local variables are fine if we can even agree on a model of the
> processing for a standard way of exposing interpreter engines' functions
as
> public interfaces.  If AIML includes explaining the program structure of
how
> it is accomplished, then talk of the values of what variables really are
> makes sense to me.  Otherwise there is no difference between a fancy text
> file or a robust database management environment or a roaming block of
> memory, in my mind, as to what predicates really represent.  They are not
a
> programming element nor a storage device without that confirmation of how
> they can be externally accessed by another computer process.  At the
moment
> they are not even guarenteed to be serialized into XML like the AIML is.
So
> what good would SOAP be for such a thing to exchange across interpreters
> (remember SOAP requires variables or parameters to be useful)?

A predicate is a string. Everything from the point of view of an interpreter
is a string, and it always has been. I don't see why this needs to change.

Jon