From: Bruce Feist
Subject: Novice LISP Question
Date: 
Message-ID: <731870950.AA00000@blkcat.UUCP>
CLG> Should I setf cars and cdrs as I  did in the
CLG>    example I posted, or should I rplaca and rplacd?  Why?

CLG> It makes no difference; they are the same.  (setf (car x) 1)
CLG> is converted into (something like) (rplaca x 1) by the
CLG> compiler.  I personally prefer using SETF in this case since
CLG> I don't have to remember argument order.

CLG> I think the issue you're really trying to get at is whether
CLG> to use destructive operations or whether to allocate new storage.  

Actually, that's not what I was doing.  Both approaches that I'm considering are
destructive.  That should be safe in these cases, since I'm manipulating the
structures *only* with the access functions I'm defining (and besides, the
structures themselves are pretty trivial -- two pointers to numbers). It was
more of a stylistic question, and also checking on whether or not I was right in
believing that the effects would be identical.

I had two reasons for wanting to do this destructively.  First, there's one of
convenience; I didn't want unnecessary SETQs floating around in the program. 
More fundamentally, I didn't want to start building new CONS cells every time I
turned a stopwatch on or off.  I'm planning to use these things mostly to
measure the performance of other LISP functions, and if they don't run quickly
(or if they start invoking lots of garbage  collection), they won't be useful.

I didn't follow your point about argument order with SETF, by the way -- both
SETF and RPLACA take two arguments which must be in the right order.

Bruce
From: Carl L. Gay
Subject: Re: Novice LISP Question
Date: 
Message-ID: <CGAY.93Mar11153744@majestix.cs.uoregon.edu>
   From: ···········@f615.n109.z1.fidonet.org (Bruce Feist)
   Date: 10 Mar 93 6:40pm PST

   BF> Should I setf cars and cdrs as I  did in the
   BF>    example I posted, or should I rplaca and rplacd?  Why?

   CLG> It makes no difference; they are the same.  (setf (car x) 1)
   CLG> is converted into (something like) (rplaca x 1) by the
   CLG> compiler.  I personally prefer using SETF in this case since
   CLG> I don't have to remember argument order.

   CLG> I think the issue you're really trying to get at is whether
   CLG> to use destructive operations or whether to allocate new storage.  

   Actually, that's not what I was doing.  Both approaches that I'm considering are
   destructive.  That should be safe in these cases, since I'm manipulating the
   structures *only* with the access functions I'm defining (and besides, the
   structures themselves are pretty trivial -- two pointers to numbers). It was
   more of a stylistic question, and also checking on whether or not I was right in
   believing that the effects would be identical.

If you mean the effects of RPLACA and (SETF CAR) then the answer is
yes, they are identical.  If you mean "both approaches" then I can't
answer because you haven't said what the 2nd approach is yet.  Sorry
if I'm just being dense...

   I had two reasons for wanting to do this destructively.  First, there's one of
   convenience; I didn't want unnecessary SETQs floating around in the program. 
   More fundamentally, I didn't want to start building new CONS cells every time I
   turned a stopwatch on or off.  I'm planning to use these things mostly to
   measure the performance of other LISP functions, and if they don't run quickly
   (or if they start invoking lots of garbage  collection), they won't be useful.

Right.  I probably should have said that for this particular case
destructive operations seem like the right thing.  

   I didn't follow your point about argument order with SETF, by the way -- both
   SETF and RPLACA take two arguments which must be in the right order.

Just that because SETF is used so often I already *know* it's argument
order: (setf place value).  rplaca might be (rplaca cons value) or
(rplaca value cons), but I don't use it very often so I have to think
about it for a microsecond.  I find (setf (car x) val) more readable
anyway.