From: Darryn Kozak
Subject: X windows and Lisp
Date: 
Message-ID: <1281@mmm.UUCP>
Hi,

	We are interested in "combining" the X window system and Common 
Lisp together. We are writing our  application on Unix and X based
workstations. Our current intentions are to use X and Motif for our 
user interface, but to keep our application in Lisp.

	Is anyone else doing this? There does seem to be alot of interest
in X amongst the Lisp community, but is anyone using it to develop 
applications? What supported products are there? Are either CLUE or CLX 
supported? Are they "portable"?

	THIS IS IMPORTANT:
	What is the easiest way to take advantage of existing widget 
toolkits(such as Motif) from lisp? Does CLUE provide any help here?

	Where should the line between C and Lisp lie. That is, where should
the control of the application be? It appears that all of the Xlib and Xt
data structures must remain in C. Where does CLOS(Common Lisp Object System)
fit into this? Should there be CLOS objects for windows and widgets, even
thought they already have C structures?

	I am interested in hearing how others taking advantage of X from Lisp.
I think some discussion on the net would be helpful, although I don't know
if it should be in comp.lang.lisp or comp.windows.x (so I've posted to both).


	Thanks,

        Darryn Kozak

        3M Center
        260-6A-08
        St. Paul, MN 55144

        phone: 612-624-1269
        leave messages: 612-733-3271
        email: ·····@mmm.3m.com
	fax: 612-733-2165
From: Andrew V. Royappa
Subject: Re: X windows and Lisp
Date: 
Message-ID: <7217@medusa.cs.purdue.edu>
In article <····@mmm.UUCP>, ·····@mmm.UUCP (Darryn Kozak) writes:
> 	We are interested in "combining" the X window system and Common 
> Lisp together. We are writing our  application on Unix and X based
> workstations. Our current intentions are to use X and Motif for our 
> user interface, but to keep our application in Lisp.
> 
> 	Is anyone else doing this? 

I have implemented some algebra algorithms in Lisp and am building
a front-end for them based on X. I chose a display-oriented front-end 
since it would be friendlier and because my application needs to produce
graphical output (draw curves, surfaces, etc.). I would like my application 
to be widely used and so I try to minimize the environment necessary to
run it in, meaning I decided not to use packages such as CLX and CLOS.
My application will need Common Lisp, X, and a Lisp <-> C interface.

The basic design is that the Lisp process will call a certain C
routine to start up the user interface (call is "UI()"). 
This routine will not return until the application quits. What the
UI() routine will do is present the user with a tool containing
a few windows, mainly a text window and a graphics window. When
the user types in some text and selects a button, the text is
passed by the UI() routine to the Lisp program, by calling a
Lisp function (the text is passed as a string argument). The
Lisp function computes whatever command the text string describes,
and returns a string containing a series of graphics commands to the UI().
The UI() displays the graphics commands on the graphics window.


> 	Where should the line between C and Lisp lie. That is, where should
> the control of the application be? It appears that all of the Xlib and Xt
> data structures must remain in C. 
> 

So to summarize, although the Lisp program starts up the (C based)
user interface, the user interface really has control over the
application (uses subroutine calls to Lisp to perform computations).

I am comfortable coding in both Lisp and C, but prefer
coding graphics/window operations in C, and symbolic math type 
operations in Lisp. So I separate the two portions and have
a simple well-defined interface between them (subroutine calls
passing and returning strings), and neither side needs to know
anything about the other.

More discussion on this would be interesting. I invite comments
on my approach (always willing to listen to good ideas).

				Andrew V. Royappa
				Purdue University
				···@purdue.edu
				{ihnp4, pur-ee, ucbvax}!purdue!avr