[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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).