Re: Pengine ask and success template

On Mon, Feb 10, 2014 at 1:05 PM, Jan Wielemaker <[email protected]> wrote:
> On 02/10/2014 12:10 AM, Torbjörn Lager wrote:
>
>>> Yes :-) that still means you must access the data using the somewhat
>>> hard to interpret data[0].args[0] and data[0].args[1] if my memory suits
>>> me well. Right?
>>
>>
>> No, hangon, that is not the way that it used to work! It used to be
>> done like this, i.e. in the way that you write below:
>>
>>           data[0].X and data[0].Y
>>
>> So hopefully your memory does NOT suit you right. :-)
>
>
> Great.  I didn't change anything :-)

Good. :-)

> It does raise the question what is
> the point of the template for the JavaScript client in the first place?
> Seems like selecting variables, no?  What about using the toplevel
> convention if you enable
>
> :- set_prolog_flag(toplevel_print_anon, false).
>
> This causes all _X variables (i.e., the convention you use for
> `named singletons') to be ignored in the result.

That's a brilliant idea, very natural and prologish!

Hmm, but still there is use for the template option on the Prolog
side, yes? If yes, this means that the way you select your variables
of interest will differ between Prolog and JavaScript. I'm not so sure
that's a good thing.

>
>>> P.s.    Should we also allow for a new Pengine() that already involves
>>>          the create/ask (and thus is discarded after the query).  So, we
>>>          can do this for the simple cases, which will iterate over all
>>>          solutions of q(X,Y)?  Here, onsolution calls the output function
>>>          and next() and finally destroy?  It may automatically chunk and
>>>          call the onsolution function for each returned value?
>>>
>>>          new Pengine({ goal:"q(X,Y)",
>>>                        onsolution: function(data) { ... }
>>>                      });
>>
>>
>> I agree that something like this should be possible. I have been
>> playing with two ideas here:
>>
>> 1) Introduce an ask(Query) option and a template(Term) option for
>> pengine_create/1. This would allow us to return the first solution
>> already with the create event. It saves us making an extra network
>> round-trip.
>
> That would be nice, in particular for pengines you only use ones.  If
> you plan to query the pengine many times anyway, this one extra query
> won't kill you. If you use it only for one query, it halves the network
> messages.
>

Yes, advantages only, no disadvantages. But it's a kind of
optimisation, isn't it, and it requires changes in both the JS lib and
the Prolog lib. Most likely not very difficult to do, but why bother
at this stage.

Also, coming to think about it, the new options should probably be
ask(Query) and ask_options(Options) where where template(Term) should
be a possible member in Options. Something like that.

>> 2) Introduce an option that means "this pengine will only be used for
>> making ONE query, so let's kill it when we are done with one" (Don't
>> know how to name it.)
>>
>> 1) and 2) appears to be orthogonal to each other, and the combination
>> seems to do what you suggest (unless I misunderstand you). And I don't
>> see the need for a new handler such as 'onsolution'.
>
> Yes. If you give ask:Goal, it will simply come back with success, fail
> or error and the Pengine is destroyed on deterministic success, fail or
> error. Ideally, we should tell the pengine itself about this, so we do
> not need an explicit destroy from the browser. That means that the
> simple case is simply one request and response.

Yes, I agree. And this could be implemented quite easily I would
imagine. But what shall we call it? Maybe continue(Boolean) would
work?


> wrt. onsolution, this is orthogonal too.  Possibly it is a good idea
> to allow for an alternative for onsuccess that, if present loops over
> the data in the success set.  That avoids the need for a loop in the
> client and/or using data[0].  I guess the problem is that you cannot
> decide after each answer between next, stop or destroy.  Unsure ...
>
>
>>> P.s.    Should ask() now be allowed to specify new handlers?  I'd assume
>>>          that if a page create a handler to ask multiple queries, it
>>> wants
>>>          different handlers for the various queries?
>>
>>
>> I tend to think in terms of statemachines here and that
>> pengine_event_loop/1 can be seen as running a single-state
>> statemachine with transistions triggered by events (in combo with
>> conditions) and executing actions (e.g. executing a command such as
>> pengine_ask/3.
>>
>> If we in order to complement pengine_event_loop/1 also had
>> pengine_statemachine/1, we could easily define a statemachine
>> (expressed in some nice notation and maybe even partly by drawing it)
>> that would in essence be able to change from one system of handlers
>> into another when changing states. I think that would work.
>
>
> Torbjörn and state machines ... there is a small bias :-)

I confess. :-) Thinking in terms of states and events and transitions
between states triggered by events comes very natural to me. It's a
great way to model processes, procedures, interaction, protocols, etc.
I think the PLTP statemachine does a very good job at modelling the
communication protocol between Prolog and a user. Can't think of a
more intutive way.

As I see it, Pengines captures and makes explicit an aspect of Prolog
that almost seems to have been forgotten (please correct me if I'm
wrong!), namely the interactional one, the flow of communcation
between the user/client/master and the Prolog/server/slave  This
aspect is captured by the PLTP protocol and the associated
statemachine. I have a background in research on dialogsystem
management (an important component in e.g. spoken dialogue systems),
so thinking in such terms comes natural to me. For me, Prolog is both
logic and dialog, and I can't help thinking that Pengines connects the
two aspects in a rather elegant way.

> I'm more
> thinking about usage scenarios.  I can see you want to create a
> Pengine, run one query in it to fill some part of your page and
> then another to fill some other part of the page.  I guess one
> way is to use:
>
> funtion handleSuccess(data)
> { if ( data[0].Person ) ...
>   else if ( data[0].Town ) ...
>
> and than make the various ask operations use different variables,
> but this seems a bit awkward to me.

Ok, I'm with you. Yes, that would be one way to do it from JavaScript.
A bit awkward, I agree. In such cases you'd probably want to use a
statemachine framework on the JS side too. ;-) I bet such a framework
can be built on top of the current pengines JS lib. I think that
should be out of scope for the current project though. (Hmm, I guess I
can put a student on the task?)

Cheers,
Torbjörn

-- 
Torbjörn Lager
Professor of General and Computational Linguistics
Department of Philosophy, Linguistics and Theory of Science
University of Gothenburg
Box 200, SE-405 30 Gothenburg, Sweden
Phone: +46317864962