extending DEFSTRUCT

[Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>]

    Date: Mon, 26 Oct 87 12:25 EST
    From: Don Morrison <dfm@JASPER.Palladian.COM>
    If you do, you probably should make it #<name-of-structure-type NNN>
    where NNN is an integer (decimal?) such that two eq structures always
    have the same number, and two not eq structures don't.  I believe this
    corresponds pretty closely to current practice for those implementations
    that do support such a beast.  The major difference, I believe, is that
    often NNN is currently an address that can change over time; it would
    probably be cleaner for eq structures to always print the same, no
    matter how manner GCs have intervened.  Since the hash or whatever it is
    you'd stick there would only need to be computed if you're printing the
    thing, I suspect it wouldn't add any serious overhead to structures
    that's not already there to support eq hash tables.
Wait a minute, EQ hash tables can't work that way; they have to work
on bignums and rationals and conses and other things that don't have
any private slot to store the hash in.  And yes, adding overhead to
structures to support this would indeed be prohibitively expensive.

On the other hand, if you don't mind having things you print never
go away in the GC, you could use EQ hash tables to implement this,
and only incur a cost for structures you actually print.  But not
having structures GC is a serious flaw, too.

I don't see that we could reasonably impose this on implementations.

Also, the octal address is often useful.  I use it all the time
when I'm debugging the mouse input code so that I can't just point
at structures with the mouse.  We used to use it a lot more, and
(sys:%find-structure-header #o234725) is sort of an idiom around
here amongst the hackers of the lower levels.  (It returns the
object; it means essentially "object at address", and figures out
the type codes).