[slime-devel] Re: per-slime-dialect slime-connected-hook implementation

[Harald Hanche-Olsen]

+ Samium Gromoff <_deepfire at feelingofgreen.ru>:

| At Fri, 01 Dec 2006 09:11:27 +0100 (CET),
| Harald Hanche-Olsen wrote:
| > 
| > + Samium Gromoff <_deepfire at feelingofgreen.ru>:
| > 
| > | Only if a let-bound variable could be made dynamic-extent, which, as
| > | far as i know (i could be wrong,) elisp cannot do.
| > 
| > Uh, as far as I know, that is the ONLY kind of let elisp knows about.
| > 
| > (The cl package for emacs works pretty hard to make a lexically scoped
| > version of let.)
| 
| Hmm, perhaps i am doing something wrong, but, i tried to replace
| the defvar + setq with a let, and now emacs says:
|     
|     error in process filter: Symbol's value as variable is void: *slime-in-dialect*

I now think that while what I said is technically correct, it was a
bit beside the point.  I only reacted to an isolated statement,
without taking the larger context into account.

And this context is very likely related to non-synchronicity: You bind
the variable *slime-in-dialect* and call slime.  But after slime has
finished its job and your function returns, the binding for
*slime-in-dialect* is also gone, and so the process filter gets in
trouble when it tries to access the variable later.

The easiest fix would be to return to using setq, but given that you
are using this variable in slime-connected-hook, I think a better
solution would be to ask the Lisp process itself what kind of lisp it
is, essentially by running something like
(slime-eval '(cl:lisp-implementation-type)) and using the response to
decide which hook to run.  (Note the importance of including the
package name on ALL symbols when you call slime-eval.  If whatever you
send to the other side causes a reader error, the slime connection
will be closed down.)

This should have the added advantage of doing the right thing when
using slime-connect to connect to an already running lisp.

- Harald