[slime-devel] swank:eval-string in wrong package?
According to the doc string for SWANK:EVAL-STRING, the string is supposed to be read and evaluated in the buffer's package. But because SWANK:READ-FORM binds *PACKAGE* to *SWANK-IO-PACKAGE* this doesn't seem to happen. Am I missing something? -Peter -- Peter Seibel peter@javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <peter@javamonkey.com> writes:
According to the doc string for SWANK:EVAL-STRING, the string is supposed to be read and evaluated in the buffer's package. But because SWANK:READ-FORM binds *PACKAGE* to *SWANK-IO-PACKAGE* this doesn't seem to happen. Am I missing something?
You are right. The docstring isn't quite correct. We could probably remove one level of printing/reading by passing a form instead of the string. We could then rename the function to EVAL-FOR-EMACS. Helmut.
Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
Peter Seibel <peter@javamonkey.com> writes:
According to the doc string for SWANK:EVAL-STRING, the string is supposed to be read and evaluated in the buffer's package. But because SWANK:READ-FORM binds *PACKAGE* to *SWANK-IO-PACKAGE* this doesn't seem to happen. Am I missing something?
You are right. The docstring isn't quite correct. We could probably remove one level of printing/reading by passing a form instead of the string. We could then rename the function to EVAL-FOR-EMACS.
Hmmm. I'm not sure that's a good idea--I was looking at this because I specifically needed to evaluate a form containing symbols I grabbed from my emacs buffer. But I need those to be read by CL in the proper package. Given the emacs s-exps and CL s-exps are *not* exactly the same it seems better to let the communication between emacs and CL be via strings. Or maybe I misunderstand you. -Peter -- Peter Seibel peter@javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <peter@javamonkey.com> writes:
You are right. The docstring isn't quite correct. We could probably remove one level of printing/reading by passing a form instead of the string. We could then rename the function to EVAL-FOR-EMACS.
Hmmm. I'm not sure that's a good idea--I was looking at this because I specifically needed to evaluate a form containing symbols I grabbed from my emacs buffer. But I need those to be read by CL in the proper package. Given the emacs s-exps and CL s-exps are *not* exactly the same it seems better to let the communication between emacs and CL be via strings. Or maybe I misunderstand you.
Perhaps the issue becomes clearer with some examples. Evaluating (+ 1 2) with C-x C-e proceeds as follows: 1. Emacs sends the string "(:emacs-rex \"(swank:interactive-eval \\\"(+ 1 2)\\\")\" nil t 477)" with a 3 byte header indicating the length to Lisp. 2. Lisp reads the 3 bytes, allocates a string and copies the string from the socket into the string. 3. Lisp READs from the string in the swank-io-package and gets the form: (:emacs-rex "(swank:interactive-eval \"(+ 1 2)\")" nil t 477) 4. DISPATCH-EVENT (or READ-FROM-SOCKET-IO depending on the communcation style) calls EVAL-STRING with "(swank:interactive-eval \"(+ 1 2)\")" 5. EVAL-STRING READs the string in the swank-io-package and calls EVAL with: (swank:interactive-eval "(+ 1 2)") 6. INTERACTIVE-EVAL reads the "(+ 1 2)" in the *buffer-package* and sends the result back to Emacs. I think we can get rid of the READ in 5. by sending "(:emacs-rex (swank:interactive-eval \"(+ 1 2)\") nil t 477)" in 1. The :emacs-rex message is created by the slime-rex macro, and the argument there is conceptually a form (where all symbols are fully qualified) and not a string. So I think we wouldn't lose any flexibility. If you need to READ in a particular package, you can use the same approach as we do for INTERACTIVE-EVAL. Helmut.
Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
Peter Seibel <peter@javamonkey.com> writes:
You are right. The docstring isn't quite correct. We could probably remove one level of printing/reading by passing a form instead of the string. We could then rename the function to EVAL-FOR-EMACS.
Hmmm. I'm not sure that's a good idea--I was looking at this because I specifically needed to evaluate a form containing symbols I grabbed from my emacs buffer. But I need those to be read by CL in the proper package. Given the emacs s-exps and CL s-exps are *not* exactly the same it seems better to let the communication between emacs and CL be via strings. Or maybe I misunderstand you.
Perhaps the issue becomes clearer with some examples. Evaluating (+ 1 2) with C-x C-e proceeds as follows:
1. Emacs sends the string "(:emacs-rex \"(swank:interactive-eval \\\"(+ 1 2)\\\")\" nil t 477)" with a 3 byte header indicating the length to Lisp.
2. Lisp reads the 3 bytes, allocates a string and copies the string from the socket into the string.
3. Lisp READs from the string in the swank-io-package and gets the form: (:emacs-rex "(swank:interactive-eval \"(+ 1 2)\")" nil t 477)
4. DISPATCH-EVENT (or READ-FROM-SOCKET-IO depending on the communcation style) calls EVAL-STRING with "(swank:interactive-eval \"(+ 1 2)\")"
5. EVAL-STRING READs the string in the swank-io-package and calls EVAL with: (swank:interactive-eval "(+ 1 2)")
6. INTERACTIVE-EVAL reads the "(+ 1 2)" in the *buffer-package* and sends the result back to Emacs.
I think we can get rid of the READ in 5. by sending "(:emacs-rex (swank:interactive-eval \"(+ 1 2)\") nil t 477)" in 1. The :emacs-rex message is created by the slime-rex macro, and the argument there is conceptually a form (where all symbols are fully qualified) and not a string. So I think we wouldn't lose any flexibility.
That makes sense to me. Though it seems like it might be nice for INTERACTIVE-EVAL to take an optional package name so one can send this: "(:emacs-rex (swank::interactive-eval \"(foo bar baz)\" :some-package-name) nil t 477)" And have the READ of "(foo bar baz)" happen in the package SOME-PACKAGE-NAME instead of *BUFFER-PACKAGE* (or in cases where there is no *BUFFER-PACKAGE*)
If you need to READ in a particular package, you can use the same approach as we do for INTERACTIVE-EVAL.
You lost me there. It looks like it just uses *BUFFER-PACKAGE*. -Peter -- Peter Seibel peter@javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <peter@javamonkey.com> writes:
That makes sense to me. Though it seems like it might be nice for INTERACTIVE-EVAL to take an optional package name so one can send this:
"(:emacs-rex (swank::interactive-eval \"(foo bar baz)\" :some-package-name) nil t 477)"
And have the READ of "(foo bar baz)" happen in the package SOME-PACKAGE-NAME instead of *BUFFER-PACKAGE* (or in cases where there is no *BUFFER-PACKAGE*)
If you need to READ in a particular package, you can use the same approach as we do for INTERACTIVE-EVAL.
You lost me there. It looks like it just uses *BUFFER-PACKAGE*.
You value of *BUFFER-PACKAGE* is derived from the package attribute in the :emacs-rex event. It was nil in the example, which means "take the current *package*". You can pass the package name to slime-rex (or slime-eval). I'd say you need a *BUFFER-PACKAGE* and another package write a should write a special function for that. Helmut.
Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
Peter Seibel <peter@javamonkey.com> writes:
That makes sense to me. Though it seems like it might be nice for INTERACTIVE-EVAL to take an optional package name so one can send this:
"(:emacs-rex (swank::interactive-eval \"(foo bar baz)\" :some-package-name) nil t 477)"
And have the READ of "(foo bar baz)" happen in the package SOME-PACKAGE-NAME instead of *BUFFER-PACKAGE* (or in cases where there is no *BUFFER-PACKAGE*)
If you need to READ in a particular package, you can use the same approach as we do for INTERACTIVE-EVAL.
You lost me there. It looks like it just uses *BUFFER-PACKAGE*.
You value of *BUFFER-PACKAGE* is derived from the package attribute in the :emacs-rex event. It was nil in the example, which means "take the current *package*". You can pass the package name to slime-rex (or slime-eval). I'd say you need a *BUFFER-PACKAGE* and another package write a should write a special function for that.
Ah. Missed that. Okay. -Peter -- Peter Seibel peter@javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp
participants (2)
-
Helmut Eller -
Peter Seibel