[comp.lang.clos] Printer methods for conditions

scott@coyote.trw.com (Scott Simpson) (06/28/91)

SunOS 4.1.1, Sun CL 4.0
Has it been decided whether printer methods for conditions are going
to be class or instance specific? It seems a combination of both are
needed. I'll be more specific. I have a program that does a connect
system call and then checks the error returned by that system call.
The code looks like

      (loop
	...
        ;; <Try connect>
	;; <Get errno value>
	(cond
	 ((= (foreign-value errno) 61)	;ECONNREFUSED
	 (restart-case
	  (error 'connection-refused :host-name host-name)
	  (try-again ()
		     :report "Try again."
		     (unix_close fd)))) ;Loop around again on failure.

Suppose the machine I am trying to connect to doesn't have the daemon
running that I am trying to connect to. In this case Unix returns
ECONNREFUSED and I want to be able to recover. I stop in the Lisp code
above, let the user restart the daemon and try again. When I get this
error, the string "The connection to host nyssa was refused." gets
printed out before dropping in the debugger. This text comes from

(define-condition connection-refused (network-error)
  ((host-name (:reader "connection-refused-host-name")))
  (:documentation "A connection to a host was refused.")
  (:report (lambda (condition stream)
	     (format stream "The connection to host ~A was refused."
		     (connection-refused-host-name condition)))))

Now suppose I know that the reason that the connection was refused in
this particular case is that the daemon isn't running. I actually want
to print a message like

	The connection to host nyssa was refused.
	The daemon on nyssa should be restarted before continuing.

I can't just change the report method on the connection-refused
condition above to the above text or *all* conditions of type
connection-refused will print this text. In another case, I may have a
condition of type connection-refused that I want to print

	The connection to host nyssa was refused.
	You do not have permission to connect to nyssa.

That is, the first line of the above error text is class wide
specific, while the second line is instance specific. CLtL2 provides
no help for me as the behavior was not yet defined when the book was
written. I ftped the latest condition system paper (the one CLtL2
culled the condition section from) off arisia.xerox.com and came
across the following tidbit:

{Condition Methods}

    Some readers may wonder why the functions for directly accessing
    the printer for a condition are not present in this document.

    The main reason is that there is not at this time an approved
    object system for Common Lisp. As such, this document is deliberately
    silent on the issue of whether the printer is represented externally
    (as "methods") or on a per-instance basis (as "slots"). In the latter
    case, if you changed the printer, you might not have a list of all
    the instances and some might not be updated.

    This issue should be carefully reconsidered if/when an object system
    is introduced, but the conservative thing for now is to not commit
    ourselves prematurely on issues like this.

An even worse exacerbation of my problem is that the latest version of
Lucid Lisp that I am using still represents conditions as defstructs
so there isn't even a printer method for conditions since they aren't
classes. I would like to hear comments on what solution the X3J13
committee has decided on for the standard.
-- 
Scott Simpson			TRW			scott@coyote.trw.com

jonl%kuwait@lucid.COM (Jon L White) (06/28/91)

re: An even worse exacerbation of my problem is that the latest version of
    Lucid Lisp that I am using still represents conditions as defstructs
    so there isn't even a printer method for conditions since they aren't
    classes. I would like to hear comments on what solution the X3J13
    committee has decided on for the standard.

When you load in the CLOS submodule, the "defstructs" automagically
become classes (but of metaclass Structure-Class of course.)  You 
*can* define PRINT-OJBECT methods on these.

Probably a more limiting "feature" of Lucid's 4.0 release is that the 
condition system implemented is "Pitman version 18" rather than the 
emmended X3J13 proposal worked out during the past two years.  The 
differences can be annoyiing, but probably not crippling (I'm aware 
that CLIM for example has some specific workarounds for the differences.)

Somehow, the name Kim Barrett comes to mind when I think of someone
who might be able and wiling to give a summary of these differences, 
and how they would affect your usage.  Try asking kab@chestnut.com, 
if he isn't reading and replying to this list [but please, don't 
everybody start sending mail to him if he doesn't reply publicly.]


-- JonL --