TCL "tickle" interfaces to Prolog

Appeared in Volume 7/1, February 1994

terry@cs.umd.edu
Terry Gaasterland
27th July 1993

We are trying to put together a Prolog interface using tcl (along with wish and xf). But we're running into some fundamental problems.

Specifically, when TCL opens a (bidirectional) pipe (technically a file handle) to Quintus Prolog, the communication does not progress the way it does with other interactive languages (e.g. Scheme LISP). For example, in order to receive a prompt, the pipe must be flushed first. The same goes for variable binding output from a query. However, anything that is written, printed, formatted, etc. is sent through the pipe to the TCL window without flushing.

Strangely, using the exact same TCL setup with Scheme works so that anything typed into the pipe window goes straight into Scheme and anything produed by Scheme is displayed on the TCL window.

Basically, it seems that output during a Quintus session is divided into three different levels: "hard" output, including prompts, answers (post-query variable bindings); semi-hard output, including help; and "soft" output, including writes from within a program. "Soft" output comes out immediately; "hard" output waits until flushing. I tried writing a quickie meta-interpreter to call queries, but that still has tcl flushing problems.

mcguire@rdd.lmsc.lockheed.com
James Mcguire
30th July 1993

I'll make one recommendation. Tcl has a nice interface with C that allows inter-callability. Quintus Prolog also has an application programmer interface that allows inter-callability (C can call Prolog and vice versa). Thus you can call Prolog as though it were another C procedure. Thus C can be in charge of the main stack and treat Prolog as an embedded component.

Many AI environments don't provide this flexibility. They own the main stack, and they only allow you to introduce fake Prolog/lisp predicates/functions which are implemented in C. When the AI programming language insists on ownership of the main stack, your first inclination is too set up an interprocess piping arrangement as you've done. Both sides of the pipe need to parse each others stdout and feed each other stdin, and many times you run into problems.

Rather than taking your approach, why don't you exploit the power of the Quintus API and treat Prolog as "just another C function". You should be able compile your Tcl application within the same executable as Prolog. Thus a Prolog call can be the callback handlers for Interface actions (implemented in Tcl/Tk).

rance@ducati.EBay.Sun.COM
Rance DeLong
30th July 1993

Quintus Prolog already has an interface (other than the foreign language interface) for communicating interactively with another program, namely the Emacs interface! I suggest you contact Quintus about how you might exploit this existing capability as I don't think that its documented in the user documentation.

micha@ecrc.de
Micha Meier
2nd August 1993

I've made a Tcl/Tk interface to Eclipse and I didn't encounter any problems at all. My approach was different from yours, though: instead of running wish as a separate process, I have taken the wish source and made it an external C function, which was then loaded into Prolog. I have also written several trivial C functions that interface tcl_eval etc., and I have also added a Tcl command 'prolog' that can call a Prolog goal from within Tcl. This works fine - one can write Tcl/Tk scripts and start them from Prolog, and/or call Tcl/Tk commands from Prolog.

alberto@cs.umd.edu
Jose Alberto Fernandez R
4th August 1993

Is there any chance to make your interface a generic one? And perhaps make it PD. Perhaps this can be the begining of a standard Tickle library for all Prologs. The only thing to change between implementations would be the way you load the C interface.

micha@ecrc.de
Micha Meier
5th August 1993

Well it is more than that, different Prolog systems have different ways to write the external C functions. My current version is in the Eclipse format which is not suitable for any other Prolog. I'll try to make a Quintus-like interface and then make it available.

There is another problem, though. My current Tcl/Tk interface is a very light-weight one. It does not interface every Tcl command separately, all that one can do is to call tcl_eval(TclCommand). This is of course sufficient, but all the graphics has to be done in Tcl. It would be better to make a Prolog builtin predicate for every Tcl/Tk command so that one does not have to go through the Tcl interpreter. This is not difficult to do, it is only a lot of work. Another problem is that Tcl/Tk creates new commands on the fly for each new window you create, for example if one creates a button with:

button .b -command Cmd -text T

a new command .b is created and one can write commands like:

.b invoke

As it is too expensive to make new predicates at runtime, one should probably create builtins like invoke/1 which would interface to the appropriate routine. Ideally, one would drop these new commands from Tcl/Tk completely, but this would require changes in the Tcl/Tk source and then we'd get problems with new Tcl/Tk releases.

Micha Meier
Micha.Meier@ecrc.de
22nd September

I have just finished the first version of ProTcl, a Prolog interface to Tcl/Tk. It can be obtained via anonymous FTP from:
ftp://ecrc.de/pub/eclipse/progs/protcl

It is a rather simple interface: it allows the evaluation of Tcl expressions from Prolog. In some Prolog systems it is also possible to type Prolog or Tcl queries at the same time that X events are served. ProTcl has been tested on ECLiPSe and SICStus, on a Sparc 10.

Comments and suggestions are welcomed.