Lisp is not meant to be started every time anew. You start Lisp once, then you re-program the running Lisp program by loading Lisp code, and then you control everything from the REPL.

It's like your first program: Start Lisp (once), load LTK (once), load your Lisp code (once), then load and plot data-files as many times as needed, but do not quit Lisp after every data-file, because the "load Lisp, load LTK, load code" overhead is not small.

I'm also wondering that LTK seems to lack the most important property of Lisp (and Tcl/Tk as well): interactive programming.

I'm currently investigating lisp2wish, one of the predecessors of LTK, to write a specialized interactive Tcl/Tk canvas handler. Then afterwards I will try to integrate the code into LTK. I don't understand the LTK :serve-event input-handler machinery enough to modify LTK right now, I first must try out what's important and what not.

I've discovered another problem that I hadn't thought about: Emacs SLIME can't send new REPL input while CL evaluates a Lisp form. This has to the consequence that I can't write a CL stream dispatcher (a function that reads from multiple input streams) for the SLIME input stream, because SLIME can't send new characters from the REPL while CL evaluates the dispatcher loop and new characters reach CL only after the loop has stopped. In a terminal window the dispatcher works, but with Emacs and SLIME it doesn't. Silly but true.

It looks as if my idea evolves into a too much doctoral thesis for my taste and meanwhile I think it would be easier to use a Tcl/Tk text widget to implement a simple control REPL for the canvas, what I will try next. This way the Tcl/Tk event loop can be used to control the REPL and the canvas, and nobody would be forced to use Emacs to control the whole thing.

If you don't care about the output going to the repl then you can just write a helper function that spawns threads to do the work (bordeaux-threads is a portable library for doing this), for a bit more effort you can have a thread pool so that you never try to run more requests than processor cores you have free.

Using a Tcl/Tk text widget for the REPL automatically synchronizes the CL REPL with the Tcl/Tk wish event loop because Tcl/Tk cannot send multiple widget callbacks at the same time.

Meanwhile I think that the event loop synchronisation is the main reason why LTK has no built-in capabilities for interactive programming (except the non-portable :serve-event machinery, that works with CMUCL and SBCL only).

Of course everybody is free to write a thread-based framework for this task (and thanks again to pjstirling for the pointers), but I think that this is just simply too much work for a small turtle and plotting canvas.