> * Courageous <jkras...@san.rr.com> > | Take a step back.
> let me know when your advice has worked for you. make an effort to show > that you can listen to anything but your own voice while you're at it.
> #:Erik
It's good advice for both of you.
Speaking as a one-time Lisper wandering in the the C++ wilderness for years, I think some more slack could be shown to users of other languages who stumble into comp.lang.lisp, either because they've just gotten into Lisp or for whatever reason. Topics such as "How do I do a deep copy in Lisp?" cause blood pressures to rise because Lispers know it's impossible, but that's because the language is much richer and exposes one to situations where deep copy is in fact quite hard if not impossible. Deep copy is hard in C++ too, but other factors (such as primitive memory management) may discourage the use of data structures that are hard to deep copy, or classes may do a reasonable job of deep copying in limited domains (vis. the distributed object database example), so C++ers become confused and hurt when they are told that their apparently reasonable request is intractable and, by the way, silly on the face of it.
Apropos of nothing, C++ hasn't stood still and isn't quite as cretinous as it was 10 years ago. I use a C++ garbage collector (Boehm) in my work and home projects for example, and the things that are being done with templates and partial evaluation are extremely cool. I'm glad to be returning to Lisp, if only as an amateur, but the C++/Perl world doesn't totally suck.
* tom_...@my-deja.com | Unlike equality, where it matters if you compare too much, for the | semantics of a deep copy, it doesn't matter if you copy too much--it will | simply be inefficient.
when object identity matters, copying too much is destroying information. such destruction can lead to very serious errors that are impossible to trace after the fact. if you don't get it right, you're hosed. if you don't even recognize that you can get this wrong, you're hosed a priori. such is the tragic case for that hack we've been trying to teach there's more to life than his C++ wonderworld.
(do we really _need_ to educate people at this level in this newsgroup?)
* Tim Moore <mo...@herschel.bricoworks.com> | Topics such as "How do I do a deep copy in Lisp?" cause blood pressures | to rise because Lispers know it's impossible, but that's because the | language is much richer and exposes one to situations where deep copy is | in fact quite hard if not impossible.
you're missing the point, as one would expect from a bystander. it isn't the _topic_ that cause any problems. it's the dimwits who come here and ask for advice, and resoundingly _reject_ the advice they get from well-meaning, highly educated people who try to teach pigs to sing, which we know wastes your time and annoys the pig (witness the "practical" line that just _had_ to come our way) only they don't know the dimwits they try to help _are_ pigs until after a while, and then they get annoyed when the pig turns out to be severely limited in learning _ability_, too.
tom_...@my-deja.com writes: > In article <38F37055.3...@synquiry.com>, > Jon S Anthony <j...@synquiry.com> wrote: > > Any such constraints are > > _context_ specific, i.e., specific to the problem space, the various > > representations that you have chosen to to encode it, and what those > > representations _mean in the given context_. It should be completely > > clear that no general solution this is _possible_ no matter what set > > of "primitive" representations you are willing to restrict yourself > > to.
> Well, it depends on what you mean by "deep copy". The obvious > meaning is that after a deep copy, you have two references > that behave identically, but updates through one won't affect > the behavior of the other (that idea can be formalized).
> > Of course you can copy > > _any_ datastructures (and vastly simpler, more easily correct, and > > cleaner in CL than you could even dream of doing in your wildest > > fantasies in C++), but that's the _easy_ part.
> No, in fact, some very common data structures in CommonLisp > cannot be copied because they are opaque, among them closures > and streams.
Good point.
> > Knowing which parts to > > copy, when to copy, and how to copy, is the important part and the > > part which is context specific and thus impossible to generalize in > > the sense you seem to want.
> Unlike equality, where it matters if you compare too much, > for the semantics of a deep copy, it doesn't matter if you > copy too much--it will simply be inefficient.
* Tom Breton <t...@world.std.com> | Apparently he can't.
Microsoft hired Ralph Reed of Christian Coalition fame as their lobbyist in Washington to get George Dubya to be favorable to their antitrust lawsuit. this was widely considered a serious mistake, especially after the New York Times uncovered it.
I haven't hired Tom Breton as my spokesman or lobbyist, but it would be the same kind of mistake if I had.
so, can _you_ stop, Tom? but we know the answer: "apparently he can't".
> > Unlike equality, where it matters if you compare too much, > > for the semantics of a deep copy, it doesn't matter if you > > copy too much--it will simply be inefficient.
> Actually, it does matter, especially if you copy things that should be > equal so they stop being equal. If you copy things that not DAGs then > this can not only fail to preserve the semantics of your data > structure but fail to terminate, which is bad.
It depends on the definition of "deep copy" you choose. My definition is based on mutability, not any form of equality. I think that's what most people really mean by "deep copy", and that's what most systems that have it actually provide.
Conceptually, you can implement deep copy by simply copying the complete object graph of the system and returning a reference to the copy of the object referenced by the original reference. This is guaranteed to terminate and will have the semantics I describe.
Note that that doesn't mean everything is smooth sailing. For example, code that uses references into the old data data structure as, say, iteration guards will simply fail when used with the copy. And if you have objects in the Lisp data structure, like an integer file descriptor, that refer to some external state, then that external state will obviously not get copied (nor should it).
> Making things that are > only incidentally equal remain equal is only bad for efficiency.
The problem with defining equality is not things that are incidentally equal, it's that many common data structures (hash tables, splay trees, association lists, etc.) are semantically equal even though they are structurally different; mutable structures are also ambiguous from the point of view of equality.
It is possible to define general deep structural equality predicates and many languages do. They usually don't map onto semantic equality, but they are still quite useful, and generally quite conservative (e.g., mutable structures are not equal, regardless of content).
Many recent languages also have some simple conventions about what should participate in deep copies and deep equality by default, simple means for overriding that, and a standard way of communicating programmer intent to the runtime. This allows them to implement distributed object systems, object persistence, and a lot of other facilities, almost completely automatically.
In general, I think there are consistent definitions of "deep copy" and "deep structural equality" possible in Lisp, just like they are in most other languages. But these operations are probably not going to be all that useful in Lisp due to the semantics of the language: Lisp has a very general set of types, most of them are mutable, and Lisp has almost no conventions for how to define deep copy and deep equality. In languages with less mutability (ML, Haskell, ...), restricted sets of data structures (APL, Matlab4, ...), or very uniform conventions on how to define new data structures (Java, ...), notions of deep copy and deep structural equality are actually useful.
> * Tim Moore <mo...@herschel.bricoworks.com> > | Topics such as "How do I do a deep copy in Lisp?" cause blood pressures > | to rise because Lispers know it's impossible, but that's because the > | language is much richer and exposes one to situations where deep copy is > | in fact quite hard if not impossible.
> you're missing the point, as one would expect from a bystander. it isn't > the _topic_ that cause any problems. it's the dimwits who come here and > ask for advice, and resoundingly _reject_ the advice they get from > well-meaning, highly educated people who try to teach pigs to sing, which > we know wastes your time and annoys the pig (witness the "practical" line > that just _had_ to come our way) only they don't know the dimwits they > try to help _are_ pigs until after a while, and then they get annoyed > when the pig turns out to be severely limited in learning _ability_, too.
Pigs are highly intelligent. Sometimes pigs turn out to be humans under a spell. In any event, who cares if the recipient isn't receptive? Posting on Usenet is not a zero-sum game between you and someone who asks a question; you don't give up your precious bodily essence everytime you answer a question. You're educating thousands of silent readers (maybe that's a bit optimistic for comp.lang.lisp :) who may be confused about the same topic, and often as not you're educating and enriching yourself.
OK, this has nothing to do with Lisp at all anymore, so I promise not to follow up.
* Tim Moore <mo...@herschel.bricoworks.com> | Pigs are highly intelligent.
pardon me for elaborating on a saying. speaking of which, this must be a regional thing -- in some parts of the English-speaking world, people tend to use idioms almost constantly, but do not reflect on them at all, which makes them into a mere set of ersatz vocabulary, while in other parts of the English-speaking world, puns and elaborations and mixing and matching idioms and expressions to travel between many layers of meaning is considered natural. I tend to be puzzled when I meet people who don't reflect on their language, because it's hard to tell which part of the many meanings they got and which they completely missed out on.
| In any event, who cares if the recipient isn't receptive?
you do, when you take the role of a bystander and raise the discussion to a meta-level. others do, when they are in middle of the discussion that started it all. many find it very annoying to see recurring dimwits fail to get over a personal hangup or their desperately trying to recover something they are the only ones to remember they lost.
> Pigs are highly intelligent. Sometimes pigs turn out to be humans under a > spell. In any event, who cares if the recipient isn't receptive?
The more interesting question to ask is: if the recipient doesn't attach the import to your angle on a problem that you do, does it justify crumbling into hurling insult after insult like a spoiled child? Merely a rhetorical question, of course.
> In article <38F37055.3...@synquiry.com>, > Jon S Anthony <j...@synquiry.com> wrote: > > Any such constraints are > > _context_ specific, i.e., specific to the problem space, the various > > representations that you have chosen to to encode it, and what those > > representations _mean in the given context_. It should be completely > > clear that no general solution this is _possible_ no matter what set > > of "primitive" representations you are willing to restrict yourself > > to.
> Well, it depends on what you mean by "deep copy". The obvious
Which is one thing that many here have been trying to point out.
> meaning is that after a deep copy, you have two references > that behave identically, but updates through one won't affect > the behavior of the other (that idea can be formalized).
That's one meaning.
> > Of course you can copy > > _any_ datastructures (and vastly simpler, more easily correct, and > > cleaner in CL than you could even dream of doing in your wildest > > fantasies in C++), but that's the _easy_ part.
> No, in fact, some very common data structures in CommonLisp > cannot be copied because they are opaque, among them closures > and streams.
I'm not sure about streams, but I've actually copied closures in (effectively) your sense. Of course, it requires having the proper source around to do it.
/Jon
-- Jon Anthony Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari
> No, in fact, some very common data structures in CommonLisp > cannot be copied because they are opaque, among them closures > and streams.
On second thought, you're right - the kind of copy that I did for closures would not (in general) fit your definition.
/Jon
-- Jon Anthony Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari
Erik Naggum wrote: > ....in some parts of the English-speaking world, people tend to use idioms > almost constantly, but do not reflect on them at all...
This is very true.
As an example of this, when a machine is running is slow it is described as `running like a pig' or `a dog.' If you have ever tried racing either of these animals you would realise that the idiom is foolish and a more appropriate one would be `running like an IT professional'.
* William Deakin wrote: > As an example of this, when a machine is running is slow it is described as > `running like a pig' or `a dog.' If you have ever tried racing either of these > animals you would realise that the idiom is foolish and a more appropriate one > would be `running like an IT professional'.
One of the most frightening experiences I've ever had was coming across a wild boar while resting from cycling half way up a hill in Germany. It moved *really fast*. Fortunately it wasn't out to get me I think, and adrenaline can make you climb even quite steep hills at a great rate for a few hundred yards.
Courageous <jkras...@san.rr.com> writes: > I have a CLOS object which may contain an arbitrary graph of > other objects. This graph may be cyclic. I'm looking for an > easy way to deep copy the object. I've been told that > generic deep copy might be implementing by writing the > object to a stream, and then reading back from that stream. > Is this the best way of doing it? Is there another way?
> Thank you, > Joe Kraska > San Diego > CA
Later:
> A tip for some of you folks: one of the keys to successful > communication is not to assume that the other person is wrong, > but rather to figure out what they're right *for*.
I believe there's also tips and netiquette about reading the FAQ and the newsgroup for some time. Maybe you would have come across a reference to Kent M. Pitman article http://world.std.com/~pitman/PS/EQUAL.html about why there can't be an all general copy, so you'd have known not to ask the question - but maybe there aren't bad questions, just bad answers.
Also, it was an extremely bad move in your second posting to talk about c++, especially about deep copying. And later about databases, since there are some strong opinions here about "the worse is better", 90% working solutions, unfinished APIs and the like.
Later:
> pointing out that if an approach works in one language, > there ought to be a way, no matter how labyrinthine, to > achieve it in another.
Here again, you aren't going to make friends here, since the way you phrase it people will believe you implicitly said that the language requiring labyrinthine or byzanthine solutions would be Lisp, whereas it's shared opinion here that it's just the other way round.
I believe you weren't specific enough about your needs, trying to be too abstract. But with all that was pointed at you by now (esp. Bradshaw) , I also believe you should now be able to write a one-page deep graph copy that'll fit your application (more precisely the specific restrictions on data that your application manipulates). It seems to me you need at least some hashtable for detection of redundancy and some declarative interface (not necessarily MOP or even CLOS) to tell how specific limited objects and their slots must be copied.
Regards Jorg Hohle Telekom Research Center -- SW-Reliability
On 13 Apr 2000 17:01:03 GMT, Tim Moore <mo...@herschel.bricoworks.com> wrote:
>years, I think some more slack could be shown to users of other languages >who stumble into comp.lang.lisp, either because they've just gotten into >Lisp or for whatever reason. [...] >domains (vis. the distributed object database example), so C++ers become >confused and hurt when they are told that their apparently reasonable >request is intractable and, by the way, silly on the face of it.
I don't think you are being very fair: _onlY_ Erik behaves like that, everybody else in the newsgroup is normal...
Just like the proliferation of parens, he may be a minor annoyance to newbies, but fortunately, parens stop annoying you in a week, and as soon as you plonk him, he'll stop annoying you. ;-)
>Apropos of nothing, C++ hasn't stood still and isn't quite as cretinous as >it was 10 years ago. I use a C++ garbage collector (Boehm) in my work and
Interesting... Any links to this gc? O:-)
>home projects for example, and the things that are being done with >templates and partial evaluation are extremely cool. I'm glad to be >returning to Lisp, if only as an amateur, but the C++/Perl world doesn't >totally suck.
Agreed for C++, but Perl does totally suck... };-)
//----------------------------------------------- // Fernando Rodriguez Romero // // frr at mindless dot com //------------------------------------------------
* tom 98 wrote: > It depends on the definition of "deep copy" you choose. My > definition is based on mutability, not any form of equality. > I think that's what most people really mean by "deep copy", and that's > what most systems that have it actually provide.
I'm not quite sure what you mean by this. Copying immutable objects is something that I think Lisp people would find extremely uninteresting except in some special cases (like copying an object into another lisp image). But there pretty much are no immutable objects in Lisp (numbers are the only case I can think of off the top of my head, and there are special exceptions in the definition of EQ to allow the system to copy numbers secretly anyway). I'm deliberately not counting any object with components, since even if it is itself immutable, you have to know all its components are too. Obviously you could have objects which were immutable *in an application*, but that's application-dependent.
> Conceptually, you can implement deep copy by simply copying the > complete object graph of the system and returning a reference to the > copy of the object referenced by the original reference. This is > guaranteed to terminate and will have the semantics I describe.
Yes, this I think is what I called `graph copy' in my paper. But I think it's painful because you need an occurs check, unless you can rely on either being able to smash the object you are copying (as a copying GC would) or you can do a very efficient occurs check (for instance if you can get at the address of objects and rely on it not changing during the copy -- neither of which is true for Lisp -- then you can use a bitmap to check if you've seen the object before which will be 1/32nd or 1/64th the size of the address space you are interested in -- this may be prohibitive if the graph is scattered through the address space of course).
Perhaps there is some trick I don't know to doing this.
> It is possible to define general deep structural equality predicates and > many languages do. They usually don't map onto semantic equality, > but they are still quite useful, and generally quite > conservative (e.g., mutable structures are not equal, regardless of > content).
Right, so they're useless for our purposes if everything is mutable...
> In general, I think there are consistent definitions of > "deep copy" and "deep structural equality" possible in Lisp, > just like they are in most other languages.
The whole point is that there are not *useful* definitions of these things -- ((a . b) (c . d)) is equal to ((c . d) (a . b) (c . e)) as an alist, but it would be hard to define a structural equality predicate which gave you this, because it has to know that you are comparing these things *as an alist*.
I don't think we have any actual substantive difference on any of these issues in fact -- although I may have misunderstood you. I'm just trying to draw the conclusion that typically copying is extremely application-dependent and that the language cannot provide copy or equality operation which are useful in more than very restricted applications, and Lisp has done the right thing in not doing this. The implication then is that the approach Lisp should take is to provide tools which let you write copiers and equality tests, such as more MOP stuff.
* Fernando <spam...@must.die> | Just like the proliferation of parens, he may be a minor annoyance to | newbies, but fortunately, parens stop annoying you in a week, and as soon | as you plonk him, he'll stop annoying you. ;-)
but how long before the obsessed stalkers stop annoying the newsgroup?
On Fri, 14 Apr 2000, Fernando wrote: > On 13 Apr 2000 17:01:03 GMT, Tim Moore <mo...@herschel.bricoworks.com> > wrote: > >Apropos of nothing, C++ hasn't stood still and isn't quite as cretinous as > >it was 10 years ago. I use a C++ garbage collector (Boehm) in my work and
William Deakin <wi...@pindar.com> writes: > As an example of this, when a machine is running is slow it is > described as `running like a pig' or `a dog.' If you have ever tried > racing either of these animals you would realise that the idiom is > foolish and a more appropriate one would be `running like an IT > professional'.
all professionals run quickly when the boss is around.
Erik Naggum <e...@naggum.no> wrote: > * Fernando <spam...@must.die> > | Just like the proliferation of parens, he may be a minor annoyance to > | newbies, but fortunately, parens stop annoying you in a week, and as soon > | as you plonk him, he'll stop annoying you. ;-)
> but how long before the obsessed stalkers stop annoying the newsgroup?
My sentiments entirely.
I read this newsgroup for technical contents, not "social graces".
Which is why I have no intention of "plonking" Mr Naggum: His technical comments seem to be among the most reliable here.
-akr
PS: A short comment may be in order, for those of narrow mind: In this posting, I am not, repeat _not_, repeat _NOT_, trying to "kiss Mr Naggum's arse": I mean every word of what I wrote above! DS.
-- Arne Knut Roev <akr...@online.no> Snail: N-6141 ROVDE, Norway = The Gates of Hell shall not prevail: Darkness now; then Light!
> Which is why I have no intention of "plonking" Mr Naggum: His technical > comments seem to be among the most reliable here.
Look, I won't belabor how absurd that is, but to make this group usable for myself, I'll be plonking you along with him. No hard feelings, but I really have no use for his nonsense, reflected or otherwise. Don't take it personally; you made your choice, I just respond.
One of the examples in Tim's paper was very telling -- a "queue" object which contains pointers to *shared* sub-structure. If one had *any* lingering doubts about the impossibility of a "universal" or "generic" copy doing the right thing, that example would surely blow them away.
Objects may have *application*-defined internal consistency invariants which are destroyed by copying, and a general copy operator *can't* know (in general) how to preserve (or at least, restore) those invariants through the copying process.
-Rob
----- Rob Warnock, 41L-955 r...@sgi.com Applied Networking http://reality.sgi.com/rpw3/ Silicon Graphics, Inc. Phone: 650-933-1673 1600 Amphitheatre Pkwy. PP-ASEL-IA Mountain View, CA 94043
> I believe you weren't specific enough about your needs, trying to be > too abstract.
True. However, it's funny. At my place of work, I'm the one all the newbies come to for answers, because I understand that sometimes the question is wrong, and instead attempt to answer their question from the point of view of helping them achieve the solution to the problem they are facing. I also understand that they are beginners, and so I take special care to guide them through their learning process. There's more than one way of looking at things, if you get my drift.
"Can't" isn't in my vocabularly.
> But with all that was pointed at you by now > (esp. Bradshaw) , I also believe you should now be able to write a > one-page deep graph copy that'll fit your application (more precisely > the specific restrictions on data that your application > manipulates). It seems to me you need at least some hashtable for > detection of redundancy and some declarative interface (not > necessarily MOP or even CLOS) to tell how specific limited objects and > their slots must be copied.
As it so happens, I already happen to have some externalization software I wrote to handle translation of graphs of objects that don't have any internal references. My only reason for asking the question at all was that I was hoping there was some built in feature in lisp that would attempt to deep copy objects irrespective of the obvious errors that this could introduce.
No big deal, though.
More rhetorically, I wonder if the people over at Franz will be "morons" if they attempt to implement the Objects By Value section of the CORBA standard in their ORBLink product?
