[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Issue DEFSTRUCT-COPIER Writeup

Issue:               DEFSTRUCT-COPIER

References: DEFSTRUCT

Related issues:

Category: CLARIFICATION, CHANGE

Edit history: V1, 10 May 90, Sandra Loosemore

V2, 13 May 90, Sandra Loosemore (update discussion)

V3, 29 May 90, Sandra Loosemore (more comments)

Problem description:

The description of the :COPIER option to DEFSTRUCT in CLtL

states:

The automatically defined copier function simply makes a new

structure and transfers all components verbatim from the argument

into the newly created structure.

This description doesn't make it clear whether the type of the

newly created structure is copied from the argument, or is

determined by the copier function. This can make a difference

in the case where a copier function defined for one structure

type is passed an argument that belongs to a subtype of the

original type. Does the result have the "name" of the subtype

and any additional slots present in the subtype but not the

parent type, or does it have the same "name" as the parent

type and only the slots inherited from that type?

There are four proposals: ARGUMENT-TYPE, COPIER-TYPE,

UNSPECIFIED, and REMOVE.

Proposal (DEFSTRUCT-COPIER:ARGUMENT-TYPE):

Clarify that the type of the result returned by copier functions

created by DEFSTRUCT is always exactly the same type as the

argument to the copier. That is, if the argument is of a

subtype of the structure type for which the copier was defined,

then the result will also be of that subtype and include all

the slots of the subtype.

Rationale for proposal ARGUMENT-TYPE:

Some people expect this behavior.

Proposal (DEFSTRUCT-COPIER:COPIER-TYPE):

Clarify that the type of the result returned by copier functions

created by DEFSTRUCT is always exactly the structure type for

which the copier was defined. That is, if the argument is of a

subtype of the structure type for which the copier was defined,

the result will be of the supertype only and include only those

slots that are present in the supertype.

Rationale for proposal COPIER-TYPE:

Some people expect this behavior.

Proposal (DEFSTRUCT-COPIER:UNSPECIFIED):

Clarify that it is unspecified whether the type of the result

returned by copier functions created by DEFSTRUCT is the type

of the argument to the copier, or the structure type for which the

copier function was defined. (In other words, the behavior of

copier functions is well-defined only when they are passed

arguments of the exact same type for which the copier was

defined.)

Rationale for proposal UNSPECIFIED:

Some people don't know what behavior to expect.

Proposal (DEFSTRUCT-COPIER:REMOVE):

Remove the :COPIER option to DEFSTRUCT.

Rationale for proposal REMOVE:

The feature is so poorly specified it's already useless.

Examples:

(defstruct foo a b)

(defstruct (bar (:include foo)) c d)

(setq result (copy-foo (make-bar)))

Under proposal ARGUMENT-TYPE,

(type-of result) => BAR

Under proposal COPIER-TYPE,

(type-of result) => FOO

Under proposal UNSPECIFIED,

(type-of result) => either FOO or BAR

Under proposal REMOVE, users would have to define their own

copier functions to have whatever behavior they wanted.

Current Practice:

Some Lisps now implement proposal ARGUMENT-TYPE and others implement

proposal COPIER-TYPE. Some Lisps also provide a COPY-STRUCTURE

function that can be used to make an exact duplicate of any

structure object.

Cost to Implementors:

Small.

Cost to Users:

Code that relies on any particular behavior is probably not now

portable anyway. It doesn't seem like copiers are used very

much.

Cost of non-adoption:

This part of the language specification remains vague.

Performance impact:

Proposal REMOVE would save space since there would be no

normally useless copier functions generated by DEFSTRUCT.

It may be that copier functions defined by hand would be

considerably less efficient than a copier provided by the

implementation (which might make use of knowledge about the

internal layout of structures to do a block memory copy or the

like).

Benefits:

This part of the language specification becomes more precise.

Esthetics:

Leaving the behavior explicitly vague seems unnecessarily ugly.

Discussion:

Loosemore's ranking of the proposals from most to least

acceptable is: ARGUMENT-TYPE, REMOVE, COPIER-TYPE,

UNSPECIFIED.

BarMar has said he thinks the behavior should be left

unspecified.

Moon has said he favors flushing the :copier feature. Barrett

also prefers flushing :copier.

Perhaps we should consider adding COPY-STRUCTURE to the

standard?

-------


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.