Stats

  • Locked Locked
  • Replies 2
  • Subscribers 143
  • Views 13306
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

how to make 2 lists independent to each other

WTony

Hi,

I have a weird problem in my skill code that I can't explain. I need help for the explanation.

aList = list(list("a" "1") list("b" "2") list("c" "3") list("d" "4") list("e" "5") list("f" "6") list("g" "7") list("h" "8"))

bList = list("a" "b" "d" "g" "i" "j")

newList = nil

foreach(subList bList

findList = assoc(subList aList)

if(findList then

newList = cons(findList newList)

)

)

foreach(subList newList

if(member("b" subList) then

rplaca( member("b" subList) "bb")

)

)

the result is :

newList = (("g" "7") ("d" "4") ("bb" "2") ("a" "1"))

aList = (("a" "1") ("bb" "2") ("c" "3") ("d" "4") ("e" "5") ("f" "6") ("g" "7") ("h" "8"))

why aList also changed?

Does those 2 lists a linked somewhere?

How can I make them independent? So when I change the newList, it doesn't change in aList.

Thanks

Yu Hao

Parents

  • Hi Yu,

    It's not surprising in the least. SKILL attempts to keep most list operations as efficient as possible, and shares lists where it can. Your original aList is a set of list cells, each with a pointer to a sub-list. When you construct newList, you are just referencing those sub-lists again rather than making a copy of them. This is the kind of thing I always explain on the whiteboard when teaching SKILL - understanding how lists are stored helps to understand both efficiency and also the impact of destructive operators.

    This is generally a safe thing to do, because most list operations in SKILL are what are called non-destructive. However, in your second block of code, you are using rplaca, which is a destructive operator (there are very few destructive operators in SKILL). There's several ways around it (particularly if you know the structure of the list - you potentially could just avoid using rplaca), but one simple way is to use copy() to copy the sublist when creating the newList if you know you're going to use rplaca. 

    newList=nil
    foreach(subList bList
      findList = assoc(subList aList)
      if(findList then
        newList = cons(copy(findList) newList)
      )
    )

    Now if you do the block of code with rplaca, aList will be unaffected, because the newList will be independent of the contents of aList.

    Regards,

    Andrew.

Reply

  • Hi Yu,

    It's not surprising in the least. SKILL attempts to keep most list operations as efficient as possible, and shares lists where it can. Your original aList is a set of list cells, each with a pointer to a sub-list. When you construct newList, you are just referencing those sub-lists again rather than making a copy of them. This is the kind of thing I always explain on the whiteboard when teaching SKILL - understanding how lists are stored helps to understand both efficiency and also the impact of destructive operators.

    This is generally a safe thing to do, because most list operations in SKILL are what are called non-destructive. However, in your second block of code, you are using rplaca, which is a destructive operator (there are very few destructive operators in SKILL). There's several ways around it (particularly if you know the structure of the list - you potentially could just avoid using rplaca), but one simple way is to use copy() to copy the sublist when creating the newList if you know you're going to use rplaca. 

    newList=nil
    foreach(subList bList
      findList = assoc(subList aList)
      if(findList then
        newList = cons(copy(findList) newList)
      )
    )

    Now if you do the block of code with rplaca, aList will be unaffected, because the newList will be independent of the contents of aList.

    Regards,

    Andrew.

Children

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.