[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
- To: ALAN at MIT-MC, RWK at MIT-MC
- From: JONL at MIT-MC (Jon L White)
- Date: Fri, 3 Aug 79 04:30:00 GMT
- Cc: (BUG LISP) at MIT-MC
- Original-date: 3 AUG 1979 0030-EDT
VALUE-CELL vs VALUE-CELL-LOCATION
There are several internal kinds of data not yet visible
to the lisp user - value cells are one of them. The segment
table entry for value cells makes them look like some kind of
LIST cell, just so that PRINT and CAR and CDR can hack them
(if you should, perish the thought, ever get a pointer to them).
But there are other kinds of spaces, for which the the segment
table gives up with a more-or-less RANDOM description, and you
can't do any lisp-like operations with them; e.g. the "symbol-block"
space, "pdl" spaces, "system" spaces, "uuolinks" areas, etc.
Really, rather than deal with any of the questions of how to
extend these pointers into the LISP world, I'd prefer to give
only primitives which return locations (addresses) and let the
user use MUNKAM in order make the transfre explicit. There is
of course, no penalty in time or space, in compiled code,
in this approach - (MUNKAM (VALUE-CELL-LOCATION x)) is just
as fast a (VALUE-CELL x). Especially, the only known application
now for value-cell hackery is LAP, and it wants the location,
not a "pointer" of any kind, for assembly into code.
I'd like to prepare a LAP which takes this approach,
supplying the needed gap from (GET x 'VALUE) if loaded into
a LISP without the new feature; how about it guys, will
VALUE-CELLL-LOCATION be acceptable?