[alicebot-archcomm] [proposal] <get pattern=
Noel Bush
alicebot-archcomm@list.alicebot.org
Sun, 4 Nov 2001 17:55:36 +0300
The text file had a spurious item ii attached to item i under 2; ignore
the spurious item ii.
> -----Original Message-----
> From: alicebot-archcomm-admin@list.alicebot.org
> [mailto:alicebot-archcomm-admin@list.alicebot.org] On Behalf
> Of Noel Bush
> Sent: Sunday, November 04, 2001 5:52 PM
> To: alicebot-archcomm@list.alicebot.org
> Subject: RE: [alicebot-archcomm] [proposal] <get pattern=
>
>
>
> > > It might be more appropriate to invent a <response/> tag
> > which stores the
> > > result of the
> >
> > uh, template evaluation. Retreiving an unevaluated
> <template> is ill
> > defined,
> > especially if it contains <get>, <condition> or <srai>.
>
> Oh, that's true. My idea hinges on a couple of things (see attachment
> to avoid line breaks):
>
> 0. Each input path is stored, with the most recent first.
> One way might
> be:
>
> <user> RICHARD WALLACE <matched> HELLO ALICE <that> * <topic> * <with>
> Hello, Alice! <that> CONNECT <topic> *
> <user> RICHARD WALLACE <matched> * <that> WHAT ARE YOU DOING <topic> *
> <with> I am writing more targets. <that> WHAT ARE YOU DOING <topic> *
>
> 0a. Matches on identical paths overwrite one another.
>
> 1. Each time a <set> is performed, the new value is stored and
> associated with the input path. The previous values are retained.
> Might look like:
>
> <user> RICHARD WALLACE <predicate> doing <after> I am writing more
> targets. <was> writing more targets
> <user> RICHARD WALLACE <predicate> doing <after> I'm eating
> lunch. <was>
> eating lunch
>
> 2. Each time a <get> with a pattern and/or that and/or topic attribute
> is performed, the engine "reconstructs" the original
> situation, by going
> through the following steps:
>
> i. The given path (from the pattern, that and topic attributes) is
> sought in the stored inputs.
> ii. The category associated with the path is retrieved.
> iii. Each time a <get> with a name attribute is encountered in the
> retrieved category's template, the engine steps backwards through the
> different values that may have been assigned to the
> predicate. It does
> this by stepping backwards through inputs until it finds the first one
> that matches an input associated with the setting of a
> predicate value.
> iv. The value that the predicate had at the time the retrieved
> category was used is used to re-process the template (so
> conditions are
> handled right).
> v. Srais are handled no differently: the values captured by the
> wildcards in the category's pattern, that and topic will be the same
> because the entire path was retrieved.
>
> 3. It's true that <random> probably presents the funniest
> problem. How
> to retain the notion of reconstructing the response?
>
> To me it is worth giving up the idea of retrieving the exact random
> response, in order to retain this "reconstruction" notion.
>
> I like the notion of reconstructing the response better than just
> storing the response because it offers the change to *use*
> the contents
> of the template, rather than just returning the whole thing.
>