Hi,
On a number of occasions I've run across references to "locatives" in
Lisp. They seem to be frequently associated with LM's & Symbolics,
pointer-like functionality is often implied, but I've not yet come
across a definition or examples.
Any suggestions on where to look for more info, or discussion of what
they are- particularly why they may or may not be desirable would be
much appreciated.
Thanks,
Greg Menke
In article <··············@europa.pienet>,
Greg Menke <··········@mindspring.com> wrote:
>On a number of occasions I've run across references to "locatives" in
>Lisp. They seem to be frequently associated with LM's & Symbolics,
>pointer-like functionality is often implied, but I've not yet come
>across a definition or examples.
A locative is an object that can contain a reference to any cell, such as
the car or cdr cell of a cons, the function or value cell of a symbol, an
element of an array, etc. They're used in much the same way as pointers in
languages like C or Pascal: you can dereference a locative to get the
contents of the cell, and store through it to update the cell. The garbage
collector is aware of them, so if an object is moved during a GC any
locatives that point into the object will be updated appropriately.
So the following two expressions are equivalent:
(setf (cdr x) y)
(let ((l (locf (cdr x))))
(setf (location-contents l) y))
LOCF is a macro that takes an expression that accesses a cell and expands
into a form that returns a locative to that cell. LOCATION-CONTENTS may
not be the name of the function that dereferences a locative; the only
LispM manual I had was a very old Chineual, from the time when CAR and CDR
were used as the way to dereference a locative (they were still supported
in later releases, for compatibility, but I think a special function like
LOCATION-CONTENTS was defined to be more mnemonic).
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Greg Menke <··········@mindspring.com> writes:
> Hi,
>
> On a number of occasions I've run across references to "locatives" in
> Lisp. They seem to be frequently associated with LM's & Symbolics,
> pointer-like functionality is often implied, but I've not yet come
> across a definition or examples.
A locative is, conceptually, a place to store something. On the Lisp
Machine it is an immediate pointer, and they consider that criterial
to the definition (that it not cons); in other Lisps, people have made
composed datatypes that contain two slots: a closure to read the value
and a closure to store. In the Lisp machine, you do effectively:
(setq loc (locf (car x)))
and you get a pointer into the cons. You do
(setf (location-contents loc) 3
to accomplish (setf (car x) 3). and (location-contents x) to read
(car x). Of course, it's the actual location that is read out of directly;
later assignments to x have no effecton a locative.
> Any suggestions on where to look for more info, or discussion of what
> they are- particularly why they may or may not be desirable would be
> much appreciated.
Btw, implementationally, location-contents was originally called cdr.
Adding an abstract name was a latterday thing. It was too hard to
duplicate the cdr microcode for locatives to the cdr of a cons, so
they just used cdr directly. (LOCF (CDR X)) just returns X. This isn't
intended to be a statement of elegance, it's just a practical decision.
So usually if you want to make a half-cons, you prefer
(setq loc (locf (car (list nil))))
rather than using the cdr, since you get something that prints better.
One way this cdr hack is really useful is that in implementing deletion,
where you need to have a pointer to a prior location and then cdr it,
you can just start your iteration with (LOCF X) and cdring it will give
you X and then (CDR X) and so on. It's an awful pun but I've seen it
used a fair amount.
Locatives are sort of conceptually/linguistically in the same space as
places, except they are based on an object model instead of a syntax model.
Also, they are gc-friendly, so they are not like the awful things you get
in C where you point into random structure.
Kent M Pitman <······@world.std.com> writes:
> Locatives are sort of conceptually/linguistically in the same space as
> places, except they are based on an object model instead of a syntax model.
> Also, they are gc-friendly, so they are not like the awful things you get
> in C where you point into random structure.
YM 'random memory'. C pointers can point anywhere. Not just into
structured data. They get used for memory-mapped IO, for instance.
This is part of what makes C programming so much fun.
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
In article <··············@kappa.unlambda.com>,
James A. Crippen <·····@unlambda.com> wrote:
>Kent M Pitman <······@world.std.com> writes:
>
>> Locatives are sort of conceptually/linguistically in the same space as
>> places, except they are based on an object model instead of a syntax model.
>> Also, they are gc-friendly, so they are not like the awful things you get
>> in C where you point into random structure.
>
>YM 'random memory'. C pointers can point anywhere. Not just into
>structured data. They get used for memory-mapped IO, for instance.
>This is part of what makes C programming so much fun.
To be fair, the C specification doesn't say this. The only way to make a
valid pointer is by taking the address of an existing object. While some
implementations may provide ways to make random pointers, that's not part
of the language.
Similarly, I believe there are subprimitives on the LispM that allow you to
create arbitrary locatives from raw memory addresses. They were used in
the bowels of the OS for things like memory-mapped I/O buffers, i.e. the
same kinds of things that random memory pointers are used for in other
operating systems. :)
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> In article <··············@kappa.unlambda.com>,
> James A. Crippen <·····@unlambda.com> wrote:
>
> > YM 'random memory'. C pointers can point anywhere. Not just into
> > structured data. They get used for memory-mapped IO, for
> > instance. This is part of what makes C programming so much fun.
>
> To be fair, the C specification doesn't say this. The only way to
> make a valid pointer is by taking the address of an existing object.
> While some implementations may provide ways to make random pointers,
> that's not part of the language.
Technically, yes. ISTR that you couldn't easily create random
pointers with Symbolics C. (Which also had an interesting concept of
NULL.)
I should have appended the disclaimer that in most implementations,
particularly on Unices and under Windos, C pointers can point
reandomly. They'll often get you a segv for your troubles, though.
Under Windows you'll just get weird behavior until some program
finally blue-screens out of frustration.
> Similarly, I believe there are subprimitives on the LispM that allow
> you to create arbitrary locatives from raw memory addresses. They
> were used in the bowels of the OS for things like memory-mapped I/O
> buffers, i.e. the same kinds of things that random memory pointers
> are used for in other operating systems. :)
Yup. They proved necessary for efficiency raisins. But mere users
weren't supposed to know of their existence (except when cozying up to
the debugger). Didn't help, I met locatives in my first session on a
Symbolics box, when I managed to crash the window system (that was
fun).
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.