I mean something analogous to COPY-STRUCTURE but for copying class instances.
I am thinking of something like

(defgeneric copy-instance (object) ... )

which returns a fresh object of the same class. Bound slots in the
object argument will have the same value in the fresh object ; unbound
slots in the object argument will be unbound in the fresh object.

CL doesn't offer convenient facilities to write it yourself either [although
a built-in construct could probably be made faster by using knowledge of
internals]. For example if it it had something like

(defgeneric slots-list (class) ...)

which returns a list of the names of the slots for the class , it would help.
Or you could have analogous constructs which return additional information
for the class like the names of initargs , names of accessors [if any] ,
etc. But , since it doesn't have any of that , all you can do is write a
wrapper for DEFCLASS which stores the information you want [like list of
slots] for further use with other macros.

--
vlaho.ninja/menu

Spiros Bousbouras <spibou@gmail.com> writes:

> I mean something analogous to COPY-STRUCTURE but for copying class instances.
> I am thinking of something like
>
> (defgeneric copy-instance (object) ... )
>
> which returns a fresh object of the same class. Bound slots in the
> object argument will have the same value in the fresh object ; unbound
> slots in the object argument will be unbound in the fresh object.
>
> CL doesn't offer convenient facilities to write it yourself either [although
> a built-in construct could probably be made faster by using knowledge of
> internals]. For example if it it had something like
>
> (defgeneric slots-list (class) ...)
>
> which returns a list of the names of the slots for the class , it would help.
> Or you could have analogous constructs which return additional information
> for the class like the names of initargs , names of accessors [if any] ,
> etc. But , since it doesn't have any of that , all you can do is write a
> wrapper for DEFCLASS which stores the information you want [like list of
> slots] for further use with other macros.

Kent Pitman has answered that one.

https://www.nhplace.com/kent/PS/EQUAL.html

--
Laat hulle almal sterf. Ek is tevrede om die wêreld te sien brand en die vallende
konings te spot. Ek en my aasdier sal loop op die as van die verwoeste aarde.

> I mean something analogous to COPY-STRUCTURE but for copying class instances.
> I am thinking of something like
>
> (defgeneric copy-instance (object) ... )

More interesting would be a functional update operation, i.e. something
like your function above but with additional parameters to set some of
the slots to different values than those of the original object.
Especially useful for read-only slots.

Stefan

On Wed, 08 Nov 2023 10:47:06 -0500
Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > I mean something analogous to COPY-STRUCTURE but for copying class instances.
> > I am thinking of something like
> >
> > (defgeneric copy-instance (object) ... )
>
> More interesting would be a functional update operation, i.e. something
> like your function above but with additional parameters to set some of
> the slots to different values than those of the original object.
> Especially useful for read-only slots.

One could come up with many variations but having at least one of those
variations available would be nice.

On 11/8/2023 1:37 PM, Lieven Marchand wrote:
> Spiros Bousbouras <spibou@gmail.com> writes:
>
>> I mean something analogous to COPY-STRUCTURE but for copying class instances.
>> I am thinking of something like
>>
>> (defgeneric copy-instance (object) ... )
>>
>> which returns a fresh object of the same class. Bound slots in the
>> object argument will have the same value in the fresh object ; unbound
>> slots in the object argument will be unbound in the fresh object.
>>
>> CL doesn't offer convenient facilities to write it yourself either [although
>> a built-in construct could probably be made faster by using knowledge of
>> internals]. For example if it it had something like
>>
>> (defgeneric slots-list (class) ...)
>>
>> which returns a list of the names of the slots for the class , it would help.
>> Or you could have analogous constructs which return additional information
>> for the class like the names of initargs , names of accessors [if any] ,
>> etc. But , since it doesn't have any of that , all you can do is write a
>> wrapper for DEFCLASS which stores the information you want [like list of
>> slots] for further use with other macros.
>
> Kent Pitman has answered that one.
>
> https://www.nhplace.com/kent/PS/EQUAL.html
The Pitman reference brings back memories. I believe I first saw it
around 20 years ago. It's well written and answers a lot of obvious
questions that one doesn't think about until they really burrow in. I
believe that reading the material will make one a much better Lisp
programmer; in particular, it illuminates many of the important issues
that need be considered when designing structures for complex
(complicated) applications and environments.
--
Jeff Barnett

On Wed, 08 Nov 2023 21:37:08 +0100
Lieven Marchand <mal@wyrd.be> wrote:
> Kent Pitman has answered that one.
>
> https://www.nhplace.com/kent/PS/EQUAL.html

The link doesn't answer what I asked. It discusses related issues and
what it says could just as well be seen as an argument in favour of
the language providing something like COPY-INSTANCE .The document
doesn't say anything about why the language doesn't give you a way
to access the information given in a DEFCLASS .

On 2023-11-09, Spiros Bousbouras <spibou@gmail.com> wrote:
> On Wed, 08 Nov 2023 21:37:08 +0100
> Lieven Marchand <mal@wyrd.be> wrote:
>> Kent Pitman has answered that one.
>>
>> https://www.nhplace.com/kent/PS/EQUAL.html
>
> The link doesn't answer what I asked. It discusses related issues and
> what it says could just as well be seen as an argument in favour of
> the language providing something like COPY-INSTANCE .The document
> doesn't say anything about why the language doesn't give you a way
> to access the information given in a DEFCLASS .

Mainly, the reason is that those kinds of things are in the Common Lisp
Meta-Object Protocol, which is not ANSI, but a de facto standard.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-11-08, Lieven Marchand <mal@wyrd.be> wrote:
> Spiros Bousbouras <spibou@gmail.com> writes:
>
>> I mean something analogous to COPY-STRUCTURE but for copying class instances.
>> I am thinking of something like
>>
>> (defgeneric copy-instance (object) ... )
>>
>> which returns a fresh object of the same class. Bound slots in the
>> object argument will have the same value in the fresh object ; unbound
>> slots in the object argument will be unbound in the fresh object.
>>
>> CL doesn't offer convenient facilities to write it yourself either [although
>> a built-in construct could probably be made faster by using knowledge of
>> internals]. For example if it it had something like
>>
>> (defgeneric slots-list (class) ...)
>>
>> which returns a list of the names of the slots for the class , it would help.
>> Or you could have analogous constructs which return additional information
>> for the class like the names of initargs , names of accessors [if any] ,
>> etc. But , since it doesn't have any of that , all you can do is write a
>> wrapper for DEFCLASS which stores the information you want [like list of
>> slots] for further use with other macros.
>
> Kent Pitman has answered that one.
>
> https://www.nhplace.com/kent/PS/EQUAL.html

I don't agree with his excuses and insinuations.

For a cons argument, a COPY function should definitely behave like
COPY-LIST; there is no question about it. Pitman didn't reason this
through to the use cases.

It is true that we don't know whether a CONS is just tree structure,
a list (sequence) or an assoc list. However, code is rarely polymorphic
in that dimension.

That is to say, we rarely write the same piece of
code that receives a cons argument which is either just tree structure,
a list or an alist, and is supposed to do something meaningful and
specific, without knowing which.

We do have this situation: code receives a sequence and wants to operate
on it uniformly, yet have it work for arrays, strings or lists.

For instance, we can imagine this function:

(defun non-destructive-sort (sequence predicate :key (key #'eql))
(sort (copy sequence) predicate :key key))

Code that knows it is working with alists or tree structure knows
the specific copy operation it needs.

Pitman apperas to be making exuses for EQUAL; but EQUAL is not nicely
defined, even if we take into account all the issues he discusses in the
article. Nothing in the article excuses the fact that EQUAL considers
two sequences to be equal by content if they are lists, but by address
if they are vectors, except when they are strings which is by content
again.

We should consider EQUAL to be related not to COPY, but to the entire
class of functions which make a similar object from an example object.
COPY is a small subset of that class; therefore it is fallacious to equate
all the issues of COPY with those of EQUAL.

Here is what I mean. Equality functions can apply arbitrary
transformations to the elements of an object; they can project the
object or its constituent elements to other values and then compare
those values instead.

A COPY function should never do that.

So that is to say, for instance, EQUALP considers the string "Foo"
and "fOO" to be equivalent. But we would never have a function called
COPY which, given "Foo", produces "fOO". It might be useful to have a
function which does that, but it wouldn't be understood as an object
copying function.

If I have to be somewhere across town in 45 minutes, I might consider a
Toyota Echo and a Porsche Carrera to be equivalent. A car copying
machine that produces a Toyota Echo when presented with a Porsche would
be considered comically defective, though.

A copy function may not change the values. The only variations allowed
in copying are:

- how much of the original object to reuse versus newly allocate

- of a object made of linked nodes
- how much of the graph shape to preserve
- handle circularity or not

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.