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

[Kim Sullivan]

> <set/>	=>	<set><star/></set>   .
>
> Or just a typo? Varname missing? Should read:

Shorthand? :-)

> And we don't need a special tag <clear>. The only change should be to
> allow the absence of content in <set>. So:

Which isn't disallowed either, so everything can stay the way it is :-) The
spec does not explicitly define the category "aiml-template-elements" but
from the description in chapter 7 it means "zero or more AIML template
elements mixed with character data".

> 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.

I think that all variables "exist" at least potentially, you don't get an
undeclared/undefined variable error if you <get> a value before you <set>
it, or test a previously unknown variable.

> - 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'.

To me, the value '' is the same as no value, and the value '0' is a string
like any other, since there's only one type (or none depending on how you
look at it). If we decided to introduce types then 0 would be the empty
value of numerical types.

> 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.

I think the empty value would be the semantic equivalent of the zero value?
Empty means false, otherwise true.

> Therefore I'm against something like 'exists' in AIML - it might
> irritate more than help.

I agree with this.

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

I agree with the above, I'd just add <li value="">empty or undefined</li>.
Unfortunately, due to the inconsistency when matching empty strings to
wildcards (this includes the context like <that> as well!) you probably
won't get to the default, at least in D. Then again, when we "fix" this,
then all the stuff with the default "*" value for <that> and <topic> stops
working in some cases.

How about we apply the same principles that are shown in the above example
to category matching as well? I mean, the common syntax for <that> and
<topic> works like this already (even if it substitutes the "one or more"
wildcards as per spec, it actually matches absolutely all strings and has to
be handled in the code provding a "false" word in case the input, that or
topic are empty strings), the only thing that would change would be the
option to also omit the <pattern>.

> 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.

I personally would like to see this as an option in a debugger/AIML editor,
having the freedom of just using variables instead of having to declare them
is nice when writing categories. I come from a pascal background and I can't
imagine how I'd feel if I had to maintain 150 global variables that could be
declared only in a file separate from the code...
Can we (the interpreter authors that is) agree to use D-style startup files
for this? It would be a nightmare downloading a set and having to manually
check all files for used variables and declaring them before being able to
use it.

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

I'd be for just ''. Not having the option of an empty or zero value of some
kind (zero length string, null pointer, 0...) seems somewhat backward. Even
in languages that require you to declare and initialize variables you can
initialize them to be empty, and test for empty.

> And what should <condition name="it" value="*"> evaluate to? 'true' -
> because the string 'something' is returned, 'false' - because the actual
> value is '' ?

False. I think that having this "default" value that is returned every time
a variable is empty is a bad idea. Having a way to initialize variables is
OK.

Kim