Hi guys,
I have been googling this newsgroup for a while and I know that copy-
instance on user defined objects is not a very good idea because of
issues like sharing and cycles, however, is there any portable way to
copy a built-in (not user defined) lisp objects?
something which would nicely fit into
(defmethod simple-copy-instance ((object built-in-class))
... code here ...)
Thanks for any ideas,
Karol Skocik
On Jun 12, 8:54 am, Karol Skocik <············@gmail.com> wrote:
[...]
> I have been googling this newsgroup for a while and I know that copy-
> instance on user defined objects is not a very good idea because of
> issues like sharing and cycles, however, is there any portable way to
> copy a built-in (not user defined) lisp objects?
Well, even there things can get a little tricky. You start running
into issues of what you want to copy. Do you want to copy list
structure, tree structure, what? NB that copy-tree and copy-sequence
are both functions in Common Lisp that naturally do different things.
Nonetheless, you can certainly write your own functions to copy
objects that don't have built-in functions already, and then have the
methods of an appropriately defined generic function call those
functions. The fact that these are all instances of built-in classes
isn't really an issue, since generic functions can dispatch on built-
in functions.
So if you know what you want, go for it.
Cheers, Pillsy
On Jun 12, 5:52 pm, Pillsy <·········@gmail.com> wrote:
> On Jun 12, 8:54 am, Karol Skocik <············@gmail.com> wrote:
> [...]
>
> > I have been googling this newsgroup for a while and I know that copy-
> > instance on user defined objects is not a very good idea because of
> > issues like sharing and cycles, however, is there any portable way to
> > copy a built-in (not user defined) lisp objects?
>
> Well, even there things can get a little tricky. You start running
> into issues of what you want to copy. Do you want to copy list
> structure, tree structure, what? NB that copy-tree and copy-sequence
> are both functions in Common Lisp that naturally do different things.
>
> Nonetheless, you can certainly write your own functions to copy
> objects that don't have built-in functions already, and then have the
> methods of an appropriately defined generic function call those
> functions. The fact that these are all instances of built-in classes
> isn't really an issue, since generic functions can dispatch on built-
> in functions.
>
> So if you know what you want, go for it.
>
> Cheers, Pillsy
Thanks for reply. I only want to provide a default, not-too-smart
function as a part of a library, where normally this function will be
specialized for user type.
for the sequences only simple behavior (deep copying) is implemented
like:
(defmethod simple-copy-instance ((seq sequence))
(map (type-of seq) #'simple-copy-instance seq))
I was surprised that for built-ins this seems to work:
(defmethod simple-copy-instance ((x number))
x)
(defmethod simple-copy-instance ((x symbol))
x)
(defmethod simple-copy-instance ((x character))
x)
...
Interesting....
Karol Skocik
On Jun 12, 5:09 pm, Karol Skocik <············@gmail.com> wrote:
> Thanks for reply. I only want to provide a default, not-too-smart
> function as a part of a library, where normally this function will be
> specialized for user type.
I wrote a paper once on why this was a bad idea, it might even be
available somewhere. It comes down to realising that specialising on
type is not enough, you must also specialise on *intent*.
From: Kent M Pitman
Subject: Re: how to copy instance of built-in-class?
Date:
Message-ID: <u645salmt.fsf@nhplace.com>
Tim Bradshaw <··········@tfeb.org> writes:
> On Jun 12, 5:09 pm, Karol Skocik <············@gmail.com> wrote:
>
> > Thanks for reply. I only want to provide a default, not-too-smart
> > function as a part of a library, where normally this function will be
> > specialized for user type.
>
> I wrote a paper once on why this was a bad idea, it might even be
> available somewhere. It comes down to realising that specialising on
> type is not enough, you must also specialise on *intent*.
My article http://www.nhplace.com/kent/PS/EQUAL.html may make the point.
The intentional issues for EQUAL and COPY are the same.
On Jun 12, 11:49 pm, Kent M Pitman <······@nhplace.com> wrote:
> Tim Bradshaw <··········@tfeb.org> writes:
> > On Jun 12, 5:09 pm, Karol Skocik <············@gmail.com> wrote:
>
> > > Thanks for reply. I only want to provide a default, not-too-smart
> > > function as a part of a library, where normally this function will be
> > > specialized for user type.
>
> > I wrote a paper once on why this was a bad idea, it might even be
> > available somewhere. It comes down to realising that specialising on
> > type is not enough, you must also specialise on *intent*.
>
> My articlehttp://www.nhplace.com/kent/PS/EQUAL.htmlmay make the point.
> The intentional issues for EQUAL and COPY are the same.
I have already read this article, and I know that this kind of copying
it's not a good idea, but in my case it's just for experimenting with
simple examples. In case user wants to make something useful with the
library, he should specialize the simple-copy-instance.
Cheers,
Karol Skocik
On Jun 13, 1:30 am, Karol Skocik <············@gmail.com> wrote:
> I have already read this article, and I know that this kind of copying
> it's not a good idea, but in my case it's just for experimenting with
> simple examples. In case user wants to make something useful with the
> library, he should specialize the simple-copy-instance.
I think the point was that you *can't*: it doesn't have the signature
you need.
On 2007-06-13, Tim Bradshaw <··········@tfeb.org> wrote:
> On Jun 13, 1:30 am, Karol Skocik <············@gmail.com> wrote:
>> I have already read this article, and I know that this kind of
>> copying it's not a good idea, but in my case it's just for
>> experimenting with simple examples. In case user wants to make
>> something useful with the library, he should specialize the
>> simple-copy-instance.
>
> I think the point was that you *can't*: it doesn't have the
> signature you need.
To elaborate on this point a little bit, imagine that you want to use
your routine to copy a list. Do you call COPY-LIST or COPY-TREE or
COPY-ALIST? It depends on your intent. The type of the operands
doesn't give you enough information.
If you recognize this limitation and accept it and all its
ramifications (and point them out to the users of your library, even),
well, we can't stop you. :)
-- L
Karol Skocik <············@gmail.com> writes:
>
> I was surprised that for built-ins this seems to work:
>
> (defmethod simple-copy-instance ((x number))
> x)
>
> (defmethod simple-copy-instance ((x symbol))
> x)
>
> (defmethod simple-copy-instance ((x character))
> x)
>
> ...
>
> Interesting....
I wonder why you find this surprising?
It is clearly allowed under the language specification.
Or is it that you are surprised that the language specification would
allow such things?
It is one of the real strengths of Lisp's object system, that it is easy
to create new operations that work on existing objects that are not
created by you. It allows you to use the existing objects in new ways
and do new things with them. This is much nicer than the straightjacket
provided by certain other, popular object-oriented languages that tie
methods directly to classes.
--
Thomas A. Russ, USC/Information Sciences Institute