The X Windows interface is not a feature of the original XLISP interpreter. Winterp [77] (``Widget Interpreter'') is an application development environment, based on XLISP. It provides interfaces to the X Toolkit and Intrinsics and to the OSF/Motif widget set. Unfortunately, this potential candidate for building a TCAD task level environment and user interface upon it lacks two important requirements. It does not readily accommodate additional C-code layers between the X Toolkit (OSF/Motif widgets) and XLISP interpreter, which inhibits the introduction of higher-level user interface layers (VUI-Library and widget wrapping layer) to be shared among C applications, and the object-oriented interface in LISP can not easily be extended to be used by C applications in a homogeneous way.
In a first attempt to provide access to the X Windows system, a rather compact, direct interface to the X Toolkit and Athena widgets has been implemented from scratch. It turned out later that this low-level X Toolkit interface approach leads to a considerable duplication of code. Functions that create certain widget arrangements can be found both in LISP and C, or prototype functions that were originally coded in LISP are later required in interactive C applications. (This characteristic situation poses a rather general problem and will be discussed in more detail later.)
During a major redesign phase, the bindings to the user interface have finally been put onto a higher level of functionality (VUI library and widget wrapping layer) by using VISTA's Tool Abstraction Concept.
In any case, a conflict arises between the competing command-line oriented interpreter which waits for the next user input and the integrated X Windows System which waits for the next X Windows event to occur. The classical LISP read-eval-print loop must be extended to include events that are triggered by the X Windows System.
Figure 4.2: The LISP read-eval-print loop
As indicated by Figure 4.2 the original XLISP interpreter waits until the current expression typed in by the user is complete, then reads the expression (the string is turned into a LISP representation), evaluates the expression, prints the result and waits for the next expression. CPU-intensive transitions are labeled with ``$'' and wait transitions are labeled with ``*'' in the quasi-petri nets in Figures 4.2 to 4.4.
Figure 4.3: The X Toolkit event loop
Applications that use the X Toolkit always have a fixed main program which mainly consists of the event loop depicted in Figure 4.3. In order to integrate both loops in a consistent way, the standard read-eval-print loop was extended to handle also events coming from the X11 system. Figure 4.4 shows the greatly simplified synchronization strategy of the combined X Toolkit and XLISP evaluation loop.
Figure 4.4: The combined LISP and X Toolkit loop
Before the read phase, the interpreter first checks whether the queue of pending expressions needs to be emptied and optionally evaluates these ``callback'' expressions (see Section 3.2.4). Then it waits for any event coming from streams, terminal input, signals (e.g. from terminating simulator runs), or the X Windows System, using the UNIX select() call. When any of these events occurs, the interpreter puts an associated callback expression (if one has been defined) into the above mentioned evaluation queue or, in the case of terminal input, waits for completion of the expression and then evaluates it. In the next cycle of the loop, the expression is fetched from the callback queue and evaluated by the interpreter. Typical applications of callbacks are the change of parameter values, the triggering of other events like the execution of a simulator, or the execution of larger LISP programs.