Re: a problem with print-functions

[Jeffrey Mark Siskind <Qobi@ZERMATT.LCS.MIT.EDU>]

    Date: Sun, 29 May 88 19:08 CDT
    From:     Gumby@MCC.COM (David Vinayak Wallace)

        Date: Fri, 27 May 88 14:37 EDT
        From:     Stever@IVORY.S4CC.Symbolics.COM (Stephen Robbins)

            Date: Fri, 27 May 88 11:25:33 EDT
            From:     bds@mitre-bedford.ARPA

        (defstruct (foo (:print-function print-random-object))
          ...)

        (defun print-random-object (object stream depth)
          (declare (ignore depth))
          (format stream "#<~S structure ~S>"
                (type-of object)
                #+3600 (sys:%pointer object)
                #-3600 'address-unavailable))

    Here's a useful idea if you do ever intend to port your code.  Sometimes
    it's hard to tell structures apart, even if they have names, since you
    might keep "dead" ones around for debugging purposes.  So I include the
    following structure in my portable code.  Then I can use %pointer in all
    my print-functions.

I thought that I'd mention another use that I have found for including
"serial numbers" in structures and flavor objects, along the lines of what
Gumby had suggested. If you want to store either structures or flavor objects
in a hash table that is indFrom WARBUCKS.AI.SRI.COM!slug-admin Tue May 31 02:10:03 1988
Received: from RELAY.CS.NET (relay1.cs.net) by neat.ai.toronto.edu with SMTP id 341; Tue, 31 May 88 02:09:54 EDT
Received: from warbucks.ai.sri.com by RELAY.CS.NET id aa15544;
          31 May 88 2:04 EDT
Received: from Think.COM by Warbucks.AI.SRI.COM with INTERNET ;
          Mon, 30 May 88 22:11:23 PDT
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Tue, 31 May 88 01:07:45 EDT
Received: by kulla.think.com; Tue, 31 May 88 01:07:35 EDT
Date:	Mon, 30 May 88 23:47:35 EDT
From:	barmar@THINK.COM
Message-Id: <8805310507.AA16550@kulla.think.com>
To:	Tyson@WARBUCKS.AI.SRI.COM
cc:	flatau@CLI.COM, slug@WARBUCKS.AI.SRI.COM
In-Reply-To: Mabry Tyson's message of Sun 29 May 88 17:18:25-PDT <580954706.0.TYSON@Warbucks.AI.SRI.COM>
Subject: *PACKAGE* rebound by debugger

   Date: Sun 29 May 88 17:18:25-PDT
   From: TYSON@warbucks.ai.sri.com (Mabry Tyson)
   Mail-System-Version: <VAX-MM(229)+TOPSLIB(126)@Warbucks.AI.SRI.COM>
   Reply-To: Tyson@warbucks.ai.sri.com

   Sorry, Art, I think the debugger should not use the current value of
   *PACKAGE*.  Suppose you had a package that didn't inherit from anywhere
   (so you always got new symbols) and you blew into the debugger.  It would
   be rather inconvenient (especially if your program "knew" that it created
   all the symbols in the package).  It generally would be ok to use
   *PACKAGE* when that package was appropriate for code (eg, something
   that would be an arg to IN-PACKAGE or PKG-GOTO) but not when the package was
   not for code.

   I think it is appropriate for IN-PACKAGE to set the standard value of
   *PACKAGE* (but the debugger should use any old value of *PACKAGE*).

Genera already includes code that handles just the above problem.  If
you read a file in such a package into Zmacs you get a warning that
the "value of *PACKAGE* didn't pass the validation function, the
standard value will not be changed."  When you hit Suspend to get an
editor breakpoint you get reverted to CL-USER (or whatever the default
package was before you read in the file).  I think we would be happy
if IN-PACKAGE performed the same check (since all our packages inherit
from LISP).