It depends on what you mean by "interact". Is it a program interacting or a human interacting. If you mean the latter, then Swank makes sense. If the former, Swank isn't needed and is probably overkill As Sam Steingold says:
A less generic answer would be to start an extra thread which would be listening on a port and then you can connect to that port to get a lisp prompt without interrupting all the other processes currently
So you'd only need a REPL talking to a stream.
Or you could send a form by HTTP. That can help with some problems. If you just have REPL on a stream, the boundary between forms is entirely ruled by the Lisp reader, and if there's any confusion between the client and the server about this (think "reader macros"!), then you could get out of sync and the whole thing stops working. HTTP gives you boundaries that you can re-sync to. There are nice portable Common Lisp package for both client (drakma) and server (hunchentoot).
In our own Common Lisp servers, we actually do both We have two things that we use for debugging or for emergency patching:
(1) Swank is pre-loaded into the server, so if we want to get in and look around, we can run Emacs with slime, and tell slime to connect over a TCP connection. As Gail points out, you have to be careful to use the version of Slime that corresponds to the version of Swank that was pre-loaded. We do not upgrade very often so that hasn't been a problem in practice but you definitely have to do that right.
(2) We have a simple way to send one HTTP request with a Lisp form in it, which is read and evaluated. (Zach suggested this.) This is ONLY for emergencies, i.e. it must be done quickly, e.g. because your system must be highly available.
You have to be very careful with this general eval mechanism. If there were time enough to test the fix, then we would not use this mechanism at all. We'd do the fix, commit it into the source control system, rebuild the code, and do a "hot upgrade", basically a rolling upgrade across the cluster of servers. There are version issues that you have to worry about here, and we have official guidelines about how to deal with that. Ryan Davis's reply about this went into detail and I agree with him 100%. David Owen's reply, I believe, was in respect to a setup where you aren't using clustering.
Ala'a Mohammad said:
I just want to point to another possibility, however, it's specific to CMUCL using the remote package
http://common-lisp.net/project/cmucl/doc/cmu-user/ipc.html
I haven't looked, but I would guess that using drakma and hunchentoot, it could be easy to make this portable between CL implementations.
-- Dan