[slime-devel] Re: OpenMCL

[Gary Byers]

On Sat, 13 Dec 2003, Helmut Eller wrote:

>
> I think multi-threading support should "feel" like job-control in a
> shell.  Usually you only interact with the foreground thread.  There
> should be the possibility to interrupt the foreground thread if it is
> busy, to place it in the background, and to switch to another thread.
> Only the foreground thread should be allowed to pop up buffers and to
> read from the REPL.  The output can probably be mixed and just be
> inserted in the output buffer.
>

If all threads are sharing the same value of *TERMINAL-IO* etc in
some way shape or form, that's probably what it does feel like.  (In
OpenMCL's case, it feels like "job control that doesn't always work
right and can't be as hard to get right as it seems"; in some other
multithreaded lisps that I've used, it feels like "job control that
may act predictably and reliably but which some people find totally
unintuitive", and in other multithreaded lisps it may feel like "job
control that works reliably and intuitively".)

SLIME does seem to offer other ways of presenting interactive output
from, interactive input to, and debugging support for lisp threads.
Naively (I confess to not having done my SLIME homework), it doesn't
-seem- that starting a second (or third or Nth) SLIME REPL (with
associated debugging and auxiliary buffers) needs to be a whole lot
different than starting the frst session was, and whether the lisp
thread on the other end of the connection is one of many in a
multithreaded lisp or the only thread in another instance of a
single-threaded lisp or ... probably needn't matter too much from
SLIME's point of view.  If SLIME already support the notion of
multiple sessions (within a single running [X]Emacs), then I
think that the hard work of supporting this style of interaction's
already been done; if it doesn't currently support multiple sessions,
then some of that hard work might involve deciding on policy matters
(e.g., which REPL do editor commands interact with ? how is this
changed ?).

To what extent can/should a SLIME REPL be decoupled from "an Emacs
stream connected to a remote Lisp stream on one end and to an Emacs
buffer on the other" ?  (Pretty obviously, these things are already
decoupled, but it might be nice to mix and match: I could imagine
wanting to use SLIME's debugger, even if a given session/thread wasn't
running a SLIME REPL (or any other REPL, for that matter.)

There are lots of cases where I think it'd be handy to create an
IPC connection to [X]Emacs from the lisp side: to be able to
create from lisp a stream whose output appeared in and/or input
came from an Emacs buffer.  One could almost imagine as many uses
for this capability in single-threaded lisps as in multithreaded
ones.  (Those uses are maybe a little more obvious in the latter
case.)

Sorry if I'm raisng questions that could be easily answered by
looking at the SLIME sources more carefully than I have.  I think
that it's worth noting that a lot of the issues related to some
kinds of "SLIME-interaction-with-multithreaded-lisps" are common
to "SLIME-multiple-concurrent=session-support".  Whatever that is,
exactly ....


>
> Helmut.
>

Gary Byers
gb at clozure.com