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