Creating an interactive session predicate e.g. chatbot

[David]

Hi, I'm looking for information on how to implement a chatbot in
Prolog--I know I should define a predicate that has as goals repeat and
something that will allow the predicate to be fulfilled, but I don't
know how to implement something that would take input, process it, and
then ask for some more input.

--David

[Jan Wielemaker]

Typically

process(State) :-
next_question(State, Question),
ask(Question, Answer),
compute_consequences(State, Answer, NextState),
proces(NextState).

Or, are you interested in using HTTP? In that case, the Prolog version
and most likely other details of the scenario become important.

--- Jan

[Jan Burse]

David schrieb:

Check out the predicate eliza at the
end of the following file:

http://cs.nyu.edu/courses/fall11/CSCI-GA.2110-003/documents/eliza.pl

It uses state in the knowledge base with mem/1. This can be
also run multi-user in a web server when you declare mem/1
to be thread local. A couple of multi threaded Prolog systems
also provide the thread local directive.

Bye

[Jan Burse]

Jan Burse schrieb:

> It uses state in the knowledge base with mem/1. This can be
> also run multi-user in a web server when you declare mem/1
> to be thread local. A couple of multi threaded Prolog systems
> also provide the thread local directive.

But similar disclaimer as for process/1 from J. Wielemaker
applies. The process/1 gives rise to something like Erlang
Actors. In the above scenario thread local would not allow
that multiple concurrent requests for the same session would
be allowed, since thread local by definition implies only
one thread. So maybe using a model:

mem(session_id, _) /* anonymous session */

- or even -

mem(user_id, _) /* user_id = elizas patient id */

Would be more appropriate instead of thread local. And
then a call back when the session expires that would cleanup
the memory for that session. With the above model you can
talk in multiple voices to eliza, and probably totally confuse
it. We as end-users don't mind usually, its very common for
me for example that I have open multiple google search pages
but I am only logged in to google once (?1 session cookie?).

If you serialize the session with eliza through some mutex,
then you could still use thread local. But you would need to
keep the interpreter object somewhere, reassociate it with
the winning HTTP thread, and purge it when the session expires.
Not very difficult to do for example in Java, simply provide a
HttpSessionListener for your session after login (*). Hooking
into the http session can also help cleaning mem/2 when you
opt for a non-thread local solution.

Bye

(*)
http://docs.oracle.com/javaee/5/api/javax/servlet/http/HttpSessionListener.html