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

[Jonathan Roewen]

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

It could've been for that reason. And the value="" makes sense to be
disallowed, provided you have support for the experimental attributes (also
in J-Alice).

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

I don't think it is a design flaw myself. What you could do is set an empty
input to "*", as is done for empty topic and empty that (of which is
mentioned in the spec).

> 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:
>
<snip history lesson/>

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

That's true.

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

I'm in for a change .. depends what it's changing to though!

Topic is never empty .. it gets set to "*" if it has no value. It's even in
the spec that this sort of behaviour is meant to happen.

Hmm, a category without a <pattern> .. that is interesting .. I think that
could be considered valid, having an implied pattern of "*". I don't think
<pattern/> could ever be considered valid, just as <that/> isn't really
valid either. BTW, there is a mistake in the aiml pattern expression in the
spec .. it has normalConst(<space char>normalConst)+ .. the + should be an *
.. I can't remember what the code for the <space char> it has there was.

> Kim