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

[Kim Sullivan]

> > Because you're not allowed to write value="" :-)
>
> Hmm, okay then. I don't see why not though.

I agree with you, was just pointing out the flaws. Somehow, it was proposed
that the value should be a pattern (maybe to emulate the experinemtal
startswith, contains, endswith attributes).

And since the GM algorithm doesn't handle empty inputs or "null" patterns
(another design flaw I'd say), it was decided that a pattern must always be
at least a word or a wildcard. But, because you sometimes need to check if a
value has already been set or not, but can't actually write value="", the
concept of the 'default' value comes in handy so that you can to some extent
check if a variable is empty or not.

BTW, I think that originally the "default" value was more like the initial
value of the variable, not supposed to work for testing empty variables.
That use came later when people found out they couldn't test for "".

> > This is one really cryptic part of the spec I'm not too happy
> about. This
> > somehow happened when it was decided to remove "startswith" and
> "endswith"
> > and "contains" from the condition and (as an alternative) allow
> wildcards
> in
> > the value part (to be precise - AIML patterns)
>
> Since when did this become part of the spec? Last I heard, this was a
> non-spec feature of ProgramD.

What, the pattern in condition? It has somehow "sneaked" it's way into it
:-) Now for a little bit of history:

The earliest references I was able to find is are message from the general
list, dated 6.9.2001:
http://list.al
icebot.org/pipermail/alicebot-general/2001-September/000213.html

Where it is said that "originally I had in mind using the pattern language
and Graphmaster matching to unify 'name' and 'value' ... but the
Architecture Committee has not yet defined now name and value attributes
work in AIML 1.0"

But 8.9.2001 on Arch, Rich says:

"The only Boolean operation specified so far is, again, the pattern
unification of AIML.  In <condition name="X" value="Y">, the Y is a valid
AIML pattern."

(The september archives are missing from the website, you'll have to trust
me on this one). Past this point it's almost like a time paradox. Prorgam D
never did the wildcard matching in conditions (and nobody before this ever
said it should) but past this point it was almost like "this is how it was
supposed to work all along".

Interesting to note is that even when there was voting on the <if> tag (and
it's removal, then promoting condition) it seems that there never was a
formal (voted upon) definition of the semantics of the value attribute, only
an implied "as per discussion"... It was passed as a part of the whole spec
draft candidate (first submitted on Arch, 29.9.2001).

A lot of things were so "obvious" that Noel didn't check if they have
actually been voted when writing the working draft of the specification.
This is probably why I was surprised that <get name="x>foobar</get> always
returns foobar because it was "obvious" to me that the get tag returns it's
contents in case the variable "x" is empty. Reading the archives I found out
that people actually repeatedly stated that it wasn't in the specification,
until we more or less agreed to use it (Arch,22.9.2001).

But, it wasn't included in the first drafts (there was no official vote on
this, or resolution, but it was in common use). Other things were (these
also haven't been voted upon but weren't used at all), like the patterns in
conditions.

I don't think this is anyone's fault. It was a great accomplishment (esp.
Noel's since he actually sat down and wrote it up), and lots of things (and
their implications) weren't to become clear for a while, or just be
overlooked. It's still a working draft :-) So we probably shouldn't take it
as set in stone, but still open to discussion and change - we never got to
vote the working draft as a final specification.

> > Unfortunately, a pattern must (says the spec) be at least a word or a
> > wildcard - you can't have an empty pattern. This brings a little
> > inconsistency in the whole system - ever wondered why the default
> > <pattern>*</pattern> category gets activated on an empty input, when it
> > matches one or more words?
>
> That doesn't sound right. <pattern>*</pattern> shouldn't match an empty
> string. In J-Alice, it gives a no match found exception, and may
> optionally
> attempt to trigger a user-defined pattern when this happens.

Right. Other people in for a change? BTW, what happens in J-Alice when the
topic is empty? Or do you always put some value in it? I think that
<pattern/> should be valid (user said nothing), as well as omission of the
<pattern> element (works like omitting <that>, or omitting the value
attribute in a condition).

Kim