[Openmcl-devel] Strange LISP Clozure problems

[Robert Goldman]

On 10/1/10 Oct 1 -11:00 AM, Lonnie Cumberland wrote:
> Thanks everyone. You have given me some really useful information
> which should help me to re-organize a bit in my project.
> 
> It still seems strange since it looks like I will have to use
> "copy-tree" to manage the lists, and will have to find a clean
> solution for my problem.
> 
> I was using a single list approach as I described in the original
> post, but am not sure how to cleanly implement that given that, if I
> understand correctly that "replace-if and replace-if-not and rplacd
> and others" include this same type of shared data approach.
> 
> I just wanted to have a simple list of the format ((1 (1 2 ....) (2 3
> ...) 2) ......) and cleanly grow "append" elements to each of the
> internal lists as my code iterates.
> 
> Lisp is a great language, but I can see that I have a lot to learn still.

Just a suggestion --- why do you think a list is a good data structure
for this db, anyway?  If the lists are always the same length, why not
use a (fixed-length) array, which is more amenable to
in-place/destructive modification?  And, for that matter, if the first
element is the key (as it seems to be), then you could get constant time
access with aref instead of linear time access with nth or find....

Cheers,
r

> 
> Thanks again for all of the help,
> Lonnie
> 
> On Fri, Oct 1, 2010 at 11:49 AM, Jon S. Anthony <j-anthony at comcast.net> wrote:
>>
>> Hi,
>>
>> I would also suggest looking at copy-tree.  However, I would suggest
>> even more strongly to reflect on why the general case of "make copy" is
>> as vague and difficult as the general case of "is equal" and would refer
>> you to:
>>
>> http://www.nhplace.com/kent/PS/EQUAL.html
>>
>> for some great elucidation.
>>
>>
>> /Jon
>>
>>
>> On Fri, 2010-10-01 at 09:57 -0400, Lonnie Cumberland wrote:
>>> Greetings All,
>>>
>>> I am working on some code in lisp and basically have 2 lists now after
>>> originally trying with just one where I had the same problem. (I also
>>> had a plist version but still get the same problem.)
>>>
>>> I make a list for a format of
>>>
>>>
>>> ((1  nil nil 1)
>>> .
>>> .
>>> .
>>> (n nil nil 1))
>>>
>>> call it *db*. I then add some values such that the first "nil" is made
>>> into a list. [ie.. (1 (2) nil 1) ] and then do this for the whole list
>>> in *db* with the function below.
>>>
>>> (defun add-mod-pres (b)
>>>       (mapcar
>>>          #'(lambda (row) (setf  (second row) (nconc (second row) (list
>>> (mod (first row) b))))) *db*)
>>> )
>>>
>>> The problem comes when I try to make a copy of the *db* and then
>>> change some value in the "copied" db.
>>>
>>> (setf tempdb (copy-list (remove-if-not #'(lambda (row) (equal (first
>>> (last row)) (list j))) *db*)))
>>>
>>> The result I am getting is that things as also being changed in the
>>> original *db* as well and it look as though there is something going
>>> on with LISP using pointers instead of actually making a copy.
>>>
>>> The basic code problem is to have my list like:
>>>
>>> ((1  nil nil 1)
>>> .
>>> .
>>> .
>>> (n nil nil 1))
>>>
>>> and while iterating over some other lists that I have, I grow each
>>> list like the below example of a single sublist within *db*:
>>>
>>> Iteration 1
>>> (1 (2) (1) 1)
>>>
>>> Iteration 2
>>> (1 (2 1) (1 5) 1)
>>>
>>> .
>>> .
>>>
>>> Iteration 10
>>> (1 (2 1 3 4 5 4 3 2 1 0) (1 5 3 2 4 5 4 4 5 3) 1)
>>>
>>> etc....
>>>
>>> What I am currently getting is that when I modify the (1 5 .... ) list
>>> then it also seems to modify the (2 1 .....) list in the *db* and this
>>> also happens if I modify the (1 5 ....) list in the tempdb which also
>>> modifies the *db* list.
>>>
>>> There seems to be some shared memory in the lists going on and I don't
>>> know how to stop it.
>>>
>>> Could the "lambda" or "mapcar" functions be the problem?
>>>
>>> Kind Regards and have a great day,
>>> Lonnie T. Cumberland
>>>
>>> "BTE, bringing people together today to meet the world's energy needs
>>> of tomorrow......"
>>>
>>> < CONFIDENTIALITY NOTICE >
>>>
>>> The information contained in this transmission is intended only for
>>> the person or entity to which it is addressed and may contain
>>> confidential and/or privileged material. If you are not the intended
>>> recipient of this information, do not review, retransmit, disclose,
>>> disseminate, use, or take any action in reliance upon, this
>>> information. If you received this transmission in error, please
>>> contact the sender and destroy all printed copies and delete the
>>> material from all computers.
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel