[alicebot-archcomm] Predefine predicates/properties

[Gary Dubuque]

I haven't talked up in a bit because I've been busy moving to a new house.
That means my email may be disrupted and/or delayed.  But I'm still here!

Back on topic...

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.  And I quote:

>
> Implementation orientated, do stars nest through <srai> tags so when you
use
> them after </srai> they are from the current context and not from the last
> match that took place, that is, not inherited?
>
Should be!

Please see
http://list.alicebot.org/pipermail/alicebot-general/2002-December/007189.htm
l

It has been fixed for ProgramD - look around near this thread:
http://list.alicebot.org/pipermail/alicebot-general/2002-December/007161.htm
l
(the zip-links are invalid).

The next release of ProgramV will be fixed too.

Ernest


Granted these and more updates such as <that>'s and <input>'s being stacked
have not been codized in a formal document yet.  But they do hint at the
scope and local effects of categories.  It is when the more logical
operations like <condition> or <srai> or <random> are used that aspects of
programming enter into the usually simple text processing of AIML.
Combining these with the nature of <topic> and <that> builds possibilities
for a calculation engine which at times launches the discussion of
enhancements in scripting type of operators.  The formatting of various date
representations is a current example of adding to AIML things that commonly
are scripted in something like PERL or Javascript.

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.

I hope this committee brings something more to AIML and not cut it away to
some scientific abstract that can only be used to talk to some other machine
or expounded by the software priesthood.

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.

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)?

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)?

I vote to turn Dr. Wallace's Program M definitions into the standard
interfaces for all interpreters where talk about local variables and such
has a framework.  Then we can talk about activating those interfaces or more
with the new tags we add to AIML.

I don't find AIML is too cluttered to warrant housecleaning to strict syntax
solely for the sake of a single exact way of writing a symbolic expression.
-----Original Message-----
From: alicebot-archcomm-admin@list.alicebot.org
[mailto:alicebot-archcomm-admin@list.alicebot.org]On Behalf Of Jonathan
Roewen
Sent: Friday, August 01, 2003 1:41 PM
To: alicebot-archcomm@list.alicebot.org
Subject: Re: [alicebot-archcomm] Predefine predicates/properties



> Same procedure as every year, Jon: AIML-meta language as cure-all!
> It has been said enough about that.

It's not a cure all, it's an aid. It's like using a high-level programming
language instead of assembler. It gives you support for writing tricky stuff
simpler, and provides some protection from shooting yourself in the foot.
You don't need it, but sometimes it would be nice to have.

> Concerning variable scope please see
> http://cafe.bevocal.com/docs/tutorial/variables.html#270634
> or
> http://www.w3.org/TR/voicexml20/#dml5.1
> on how this is managed in VoiceXML i.e..

I've read, and it doesn't sway me one bit. Local scope is largely
irrelevant. If you want a temporary variable to last a scope, just call it
"temp", or "temp1", "temp2", and reuse it all the time .. a category itself
has no lifetime, there is little to do with hierachies as there apparently
is in VXML .. they're two different styles of applications.

The only reason you'd want local variables in AIML is if you're paranoid
about security, in which case, just erase it when you're done with it.

> And: I recommend asking in comp.lang.c++ :
>
> "Proposed change to the C++ compiler: We should ommit strict type
> definitions, all variables are in global scope and we don't need syntax
> checking."

Again, you aren't comparing apples with apples. That is plain stupid simply
because there are well defined scopes and hierachies, and well-defined
lifetimes of objects. This is not present in AIML.

> So if you challenge consistent system design, than stick with your LEGO
> bricks and continue playing with VisualBasic.

You'd be surprised what you can do with either LEGO or VB...

Jon


_______________________________________________
alicebot-archcomm mailing list
alicebot-archcomm@list.alicebot.org
http://list.alicebot.org/mailman/listinfo/alicebot-archcomm