a problem with print-functions

["David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: Fri, 27 May 88 11:25:33 EDT
    From:     bds@mitre-bedford.ARPA
    
    Now for the problem: I use forward and backpointers a lot.  During
    development I spent as much time in the inspector as I did in the
    editor.  With flavors this was no problem, since flavors print
    as "unprintable "structures.  Pointers from one flavor to another
    were no problem, and all I had to do is mouse on the slot to
    expand it.  Defstructs are another matter--they want to print
    out every slot.  This can be partially solved by using print-functions, 
    of course, but  since most of the structures have between 6 and 12
    slots (some of which are lists of other structures),
    the printouts become long and unwieldy, and the individual
    slots are not mouseable in the  inspector.  
    
    It is possible to partially solve the problem in the inspector by
    making all the defstructs unnamed vectors, which print out in a
    similar manner to flavors.  However, this is unnacceptable since
    the slot names don't show in the inspector and since I also need
    to do quite a bit of typing in the code and if the structure is
    unnamed you lose the ability to test for type (eg, if rts is an
    unnamed structure, (rts-p var) won't work.
    
    Is there a solution to this problem, or do I have to give up one
    of the best tools the Symbolics machine has to offer, ie, the inspector?
    Working with multiple debugging flags and embedded print statements
    seems a horribly wasteful solution, although I seem to be reduced
    to it.

It's certainly reasonable to want to be able to customize how the
inspector displays a defstruct.  We have not had the resources to
redesign the inspector to allow this.  Actually, redesigning the
inspector may be somewhat futile.  I personally have never again used
the inspector after dynamic windows became available, since for my
purposes dynamic lisp listeners do everything that the inspector did,
and generally do it better (albeit slower).

The function you need to patch or advise is named
(FLAVOR:METHOD :OBJECT-NAMED-STRUCTURE TV:BASIC-INSPECT)
if you want to make the inspector do something special with your
structures.

I have another suggestion: it's very easy to write code that uses
defflavor on Symbolics systems and defstruct on other systems, as long
as you never use defmethod (other than for Symbolics-specific code such
as debugging/inspecting code).  After all, the syntax of a call to a
slot access function and of a call to typep is the same for flavors and
structures.  Just make a macro that expands into defflavor or defstruct,
dependent on *features*, to define all your structures.