In Common Lisp what is a printed representation?
Asked Answered
O

2

6

I'm using SBCL, emacs, slime, and quicklisp to install various packages.

I instantiate and start a hunchentoot acceptor like so,

CL-USER> (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242))
#<HUNCHENTOOT:ACCEPTOR (host *, port 4242)>

I test by opening the browser on port 4242 and it works fine.

Then to stop it, I can copy the printed representation and issue the command, like so:

CL-USER> (hunchentoot:stop #<HUNCHENTOOT:ACCEPTOR (host *, port 4242)>)
#<HUNCHENTOOT:ACCEPTOR (host *, port 4242)>

This only works with the printed representation returned by the corresponding start.

This is surprising to me. I thought that the printed representation was simply text returned, presumably because the object itself could not be shown. As such, I thought it was pretty neat that hunchentoot:stop could use the text string to find the object. But then with more experimentation, I noticed that I had to use the printed representation corresponding to the start, not just any one. I also notice that when I put my mouse over the printed representation it highlights the entire segment. So it's not text at all but the object that is actually in the REPL, and I can use it.

So on the one hand what's returned is a print representation so I can see it, but on the other it's the actual object that I can copy and paste in the REPL. Is this right? I guess it must be because I'm doing it. This is totally amazing to me.

Any explanation or insight would be greatly appreciated.

Overdrive answered 2/4, 2013 at 23:7 Comment(0)
N
6

These are so-called 'Presentations'. See the SLIME User Manual, Presentations.

The documentation also explains what happens if the objects don't go away...

The idea mostly comes from BBN (Zdybel, et al., An Information Presentation System, 1981), then the Symbolics Lisp Machine and the portable Common Lisp Interface Manager, which records the underlying objects during output in its window system. These presentations there work for graphical and textual output and are an important basis for its user interface.

SLIME has picked up the idea for its REPL.

Neuropsychiatry answered 3/4, 2013 at 7:29 Comment(1)
Excellent. Thank you for the link to the manual, and for the Zdybel reference (Google easily finds a PDF).Overdrive
W
7

This is SLIME "magic". In fact, you can't do anything with such "print representation" in Lisp, because it is considered an unreadable object: try it in the console mode of your implementation. But SLIME remembers the association to the actual object, so it will substitute the object for that #<...> thing - kind of like a Lisp Machine...

What will work correctly and always is this:

CL-USER> (defvar *server* (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4242)))
*server*
CL-USER> (hunchentoot:stop *server*)
#<HUNCHENTOOT:ACCEPTOR (host *, port 4242)>
Webby answered 2/4, 2013 at 23:17 Comment(1)
Yes, I normally save the object just so I can stop it. So SLIME is getting the returned object and linking it to the print representation. It does this with returned lambdas too. Nice feature didn't know it was there. Except it does raise a question: what if I don't want all the object(s) still extant? Perhaps clearing the buffer kills them. It would certainly make them inaccessible. May be that's worthy of another question altogether.Overdrive
N
6

These are so-called 'Presentations'. See the SLIME User Manual, Presentations.

The documentation also explains what happens if the objects don't go away...

The idea mostly comes from BBN (Zdybel, et al., An Information Presentation System, 1981), then the Symbolics Lisp Machine and the portable Common Lisp Interface Manager, which records the underlying objects during output in its window system. These presentations there work for graphical and textual output and are an important basis for its user interface.

SLIME has picked up the idea for its REPL.

Neuropsychiatry answered 3/4, 2013 at 7:29 Comment(1)
Excellent. Thank you for the link to the manual, and for the Zdybel reference (Google easily finds a PDF).Overdrive

© 2022 - 2024 — McMap. All rights reserved.