Subject: Re: multiple copies of a CLOS object?
From: Erik Naggum <>
Date: Fri, 27 Jul 2001 21:04:08 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* Amanda Stent <>
> Is there a CLOS function for copying a CLOS object so that you end up
> with two clones that are thereafter independent?

  No.  There is no way to define "copy" such that this can be done without
  serious intervention from the creator of the class.  E.g., if you have a
  symbol as the value of a slot, do you want to copy the symbol, and if you
  copy the symbol, do you want to copy the package?  If you do copy the
  package, do you want to copy _all_ its symbols?  Obviously, this leads to
  a copy of the entire Lisp world in no time (in practice it will much more
  time).  You are better off with the Unix system call "fork".  This is not
  normally what people think of when they want a copy of an object, however.

  If you believe that a shallow copy is the right default choice in sharp
  contrast to the very deep copy described above, consider an object that
  points to itself with one of its slots.  A shallow copy would not make
  the "clones" independent at all, they would be like Siamese twins, and
  you would likely wreak havoc if you believed they _were_ independent.

  In the Common Lisp world, we do not generally believe in functions that
  work "most of the time", but look for the border conditions that make it
  necessary to point out when it works and when it does not.  A general
  "copy constructor" is not well-defined enough to make this possible.

  Besides, there is so much going on in CLOS objects that even if you
  succeed in making a copy, you may have broken many significant other
  things that depended on object identity in ways the object may not know
  about.  See also the desire to compare two objects for anything other
  than object identity.  Those who say it can be done are simply wrong,
  because the information necessary to accomplish this seemingly simple
  task is not specified by the language.  It is in the _intent_ of the
  programmer, not the _expression_ of that intent.  Until we find a way to
  write down the intent directly, we can only deal with expressions of
  intent in our programming languages.

  In other words, the PhD-level answer is "create a language such that it
  can automatically construct a copy constructor that always does the right
  thing".  It is simpler to write the code for your own copying function.

  There is nothing in this message that under normal circumstances should
  cause Barry Margolin to announce his moral superiority over others, but
  one never knows how he needs to behave to maintain his belief in it.