CLX, CLUE and LISP/X Toolkits...

["David C. Martin" <dcmartin@CS.WISC.EDU>]

I have been reading the passing mail, but haven't had time to comment until
now.

I find most of this discussion revolving around two subjects:

1) What should a LISP window system be?
2) How can X, CLX, CLUE, NeWS or ??? be a means to providing a solution to 1.

I implemented an X10 interface for Common LISP called XCL.  This is a foreign
function interface to the C Xlib functions and required mucho hacking to 
provide the semantics which I wanted in a LISP environment.

On top of XCL I began implementing XCLOS, which is an object-oriented version
of XCL, but with a difference from the CLX/CLUE path in that it did not change
the underlying structures or functions of XCL.  Granted that certain 
modifications were made to XCL in order to support some of the semantics 
required by a more complex system (e.g. searching the X event queue).

After the initial implementation of XCLOS numerous problems with speed arose.
Many of these problems had their origins in the speed of PCL, but other were
due to the object-oriented model in general (e.g. making each X event an 
object).  The overall design of XCLOS was a strict object-oriented system,
and I did not make any effort to optimize certain characteristics at the top
level (e.g. event processing).  

To solve the event processing model, I allowed the XCLOS programmer to utilize
the efficiency of XCL by registering user-defined (and some system defined)
event handling functions to particular event characteristics (much like NeWS
allows any arbitrary PostScript function to be sent to the backend to increase
performance).  What I discovered was that I achieved a drop from ~ 80 ms/event
to ~ 20 ms/event for the null event case (i.e. I asked for the event, but at
the time of receipt it was uninteresting and I chose to ignore it).  An actual
event scenario for key-pressed input events brought in processing speeds of
42 ms/event when using user-defined optimized event handling, but with every
other aspect being object-oriented (e.g. sending the putc message to the 
appropriate window).

Now back to (1) and (2):  I don't know what a LISP window system should be; I
also don't know whether X > NeWS or NeWS > X or ??? > X, ??? > NeWS.  I do know
that we have X and CLX now and both provide adequate performance across a 
variety of hardware.

The preceding information about the XCL/XCLOS system was to show that 
performace in an object-oriented system can be achieved if the OO system 
allows the user to access the non-OO system in a clean and standard fashion.

In addition, version control for the OO system can provide even greater 
optimizations by utilizing compile-time method determination (e.g. on 
``frozen'' generic-functions in the PCL/CLOS world) and in-line expansion of 
non-OO functions inside OO methods (i.e. to handle the case of putc to a window
which is based on some XCL function).  Furthermore, version-control and some
type of optimizer could generate or access optimized routines from the low
level integration methods which connect the OO to the non-OO.

I would like to see some expansion of the semantics of streams in Common LISP
to allow them to be expanded to support windows (e.g. Common Windows), but I
don't think that such support should be object-oriented, only standardized for
CL to allow OO extensions later.

Well, those are my thoughts on this subject.

dcm