[alicebot-archcomm] [proposal] <get pattern=

[Noel Bush]

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C16559.5F887E40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


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

------=_NextPart_000_0009_01C16559.5F887E40
Content-Type: text/plain;
	name="get-pattern-that-topic.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="get-pattern-that-topic.txt"

(View without word wrap.  The long lines are that way on purpose.)

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=20
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=20
performed, the engine "reconstructs" the original situation, by going =
through=20
the following steps:

   i. The given path (from the pattern, that and topic attributes) is =
sought in=20
      the stored inputs. ii. The template associated with the path is =
retrieved.
   ii. The category associated with the path is retrieved.
   iii. Each time a <get> with a name attribute is encountered in the =
retrieved=20
        category's template, the engine steps backwards through the =
different values=20
        that may have been assigned to the predicate.  It does this by =
stepping=20
        backwards through inputs until it finds the first one that =
matches an input=20
        associated with the setting of a predicate value. iv. The value =
that the=20
        predicate had at the time the retrieved template was used, is =
used to=20
        re-process the template. iv. The value that the predicate had at =
the time the=20
        retrieved template was used, is used to re-process the template. =
iv. The=20
        value that the predicate had at the time the retrieved template =
was used
   iv. The value that the predicate had at the time the retrieved =
category was used
       is used to re-process the template.
   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=20
retain the notion of reconstructing the response?

To me it is worth giving up the idea of retrieving the exact random =
response, in=20
order to retain this "reconstruction" notion.

I like the notion of reconstructing the response better than just =
storing the=20
response because it offers the change to *use* the contents of the =
template,=20
rather than just returning the whole thing.
------=_NextPart_000_0009_01C16559.5F887E40--