Hi everyone, Need some help here.

Found that some match variable was not cleared after even “:reset user”, as shown in the attached screen shot. Thought it should be reset in the next input matching or at least after “:reset topic” etc.

Causing some bug with my script based on user variables. Any advice how I may fix that? Many thanks.

Is it possible that the variable in question might be getting set somewhere within the initialization process? That’s just about the only thing that I can think of that could cause that.

Thanks for the advice Dave. It does not seem to be likely though because I’m using the default simplecontrol.txt.

Actually the value “London” of the variable was set by prior input in running the script. So I have a feeling that match variables do not get reset or cleared after the execution of each rule.

As match variables are subject to each rule with standard naming _0, _1, _2, etc., it looks to me that they should have a short life span in each rule only, and should be cleared at the start of a next rule.

match variables should be considered undefined (value unknown) at the start of a volley. After that, you have control of its contents for the remainder of the volley (bearing in mind that low numbered ones will be probably reused by various rules, but that high-numbered ones can be treated like $$vars for the duration of the volley.

Therefore :reset has no effect on match variables

Hi Bruce, 

Thank you very much for the explanation. Actually what bothers me is not the :reset effect, but that match variables are undefined at the start of a volley.

Take the following simplified rule for example:
u: ( ~i_want_to ~send *~1 [package something] {to _~location} ) if (_0) {$dest=_0} ^respond(~questions)

A valid input like “I want to send something” should ideally leave $dest null as opposed to “I want to send something to New York” which will set $dest to New York. But the match variable _0 sometimes will carry residual value from prior rules and makes the former case matched with unwanted result.

I still could not find a way to deal with this optional location input. If all match variables could be reset before execution of each rule, which seems to me the proper definition of such variable, the issue will be fixed for this common scripting requirement.

Or is there any other easier way to fix it? Appreciate any advice.

There are various solutions to your problem.

1. you could create a function which cleared match variables and insert it at the start of your pattern
u: (^clearmatch() ...)

2. you could revise your pattern to detect pieces of information somewhat independently
u: ( ~I_want_to_send *~1 [package something])
  a: (to _~location)  $dest = _0 ^respond(~questions)
  a: (*) $dest = null ^respond(~questions)

3. you could clear all match variables yourself as the first rule in your control script upon starting a volley

The last one naively appears most appealing, but #2 is actually safer, because the odds that your rule is the first rule to execute that captures _0 is pretty low.

Thank you sir, for such quick advice again. The guidance in clearing the variables looks great and I’m going to try them immediately. Many thanks again.

Meanwhile, having addressed your question…. let us look at your actual example .
u: ( ~i_want_to ~send *~1 [package something] {to _~location} )

{to _~location} is unlikely to be appropriate. You do not match:
I want to send a package to Iran
because { } is like [ ], find the first that matches and in this case then swallow it. So when “to” matches,
it does not pay attention to _~location.  What you might want is
{to} _{~location}  which would swallow to and then swallow a location if there. _0 gets set in either case, either to null or to the location.

And you might need to generalize to {to in} to match:
I want to send a package to my aunt in Paris.
and you’d need a wildcard after [package something].

Hi Bruce,  It is really awesome to have your great support in learning ChatScript the masterwork.

You just corrected my feel about {}. So yes, {to _~location} is a misunderstanding.

In addition to {to} _{~location}, if I really want “to ~location” to be an optional phrase, now I know I should write {(to _~location)}.

Your suggestion of {to in} is a good idea too.