[mcclim-devel] DESCRIBE-OBJECT methods

[Andy Hefner]

I think the underlying issue is that conses are printed via the lisp
printer, and it does not know to output the objects as presentations
so that you can invoke describe and/or the inspector on the individual
elements. The master plan (if there is one) involves writing a
portable replacement for the pretty printer that is aware of
presentations. I believe Gilbert Baumann has done a substantial
portion of this work, but the effort has stalled as he is busy
elsewhere.

An alternate stopgap measure would be a presentation method for lists
which presents each element of the list contents itself rather than
relying on the lisp printer. Then you get roped into reimplementing
the formatting and printer controls yourself..

On 6/1/05, rpgoldman at real-time.com <rpgoldman at real-time.com> wrote:
> 
> One thing that's made the built-in describe less useful for me than it
> might be is that it seems to bottom out at CONSes.  So if I have data
> structures that contain a CONS (e.g., a list-valued slot), I get
> tantalizingly close to seeing what I want to see, but then can't drill
> down any further.  [I suppose I could try invoking Clouseau...]
> 
> I believe it would be relatively straightforward to add a new
> describe-object method that would look at the contents of a CONS, but
> I'm concerned that this might be risky in the case of objects that are
> very large.  PPRINT, of course, gets around this by using
> *print-length*, and I suppose I could also, but that seems like an
> abuse of a built in.  For lack of a better, here's what I came up with
> (inserted into DESCRIBE.LISP):
> 
> (defmethod describe-object ((thing list) stream)
>   (format stream "~S is a list~%" thing)
>   (loop for x in thing
>       for i from 0
>       until (and *print-length* (= i *print-length*))
>       do (describe-object x stream)
>          (terpri stream)
>       finally (when (< (1+ i) (length thing))
>                 (format stream "...~%"))))
> 
> I don't think that the above is really right, but perhaps it's a step
> in the right direction?  Can anyone refine it?
> 
> Also, when I was editing describe.lisp, it confused my emacs interface
> a bunch, because the mode line lists specifies COMMON-LISP as the
> package, but the in-package form says CLIM-LISP.  The Allegro
> Emacs-lisp interface ignores the latter in favor of the former!
> 
> Best,
> R
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>