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

[Jonathan Roewen]

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

Yup .. too lazy. Anyways, looks like I'm going to have to add an option to
J-Alice config to disable certain extensions after this revelation of
<set/>.

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

You only need exists. In AIML, anything that exists has a value, everything
that doesn't exist has no value (the empty string). In my interpreter,
whenever there is AIML which attempts to retrieve a value of something that
doesn't exist (an out-of-bounds <star/> index, <get/> for something that
isn't <set/>), it returns an empty string. So I think exists in <condition>
would be only natural to represent the empty string.

> > - 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 see this as going backwards than forwards. What advantages does this have
over the disadvantage of having to ensure something is declared before it is
used? And in a completely different file from your knowledge base.

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

Perhaps for the <predicates> section, and the likes.

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

Perhaps so, but isn't that the whole point of it being a default value? It's
like how ProgramD returns "undefined" for most predicates when you use
<get/>.

> Kim