[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


I hope this issue is minor enough to be noncontroversial.


References:	CLtL p. 312-314
Edit History:   V1, 5 Aug 1988, Sandra Loosemore

Problem Description:

CLtL doesn't make clear whether defstructs that :INCLUDE another
structure type and do not specify a :PRINT-FUNCTION inherit the
:PRINT-FUNCTION of the parent structure type.  While it is stated on
page 314 that #S syntax is used if a :PRINT-FUNCTION is not specified,
the language on page 313 indicates that all operations on the parent
type will also work on objects of the child type.  Because of the
ambiguity, existing implementations have gone both ways, and users
cannot depend on either #S syntax or the parent type's :PRINT-FUNCTION
being used.


Clarify that defstruct types which :INCLUDE another type but do not
specify an explicit :PRINT-FUNCTION inherit the structure print
function from the :INCLUDE'd type.


Users typically specify a print function for a structure type because
its slots will contain circular objects or large internal data
structures which are confusing when printed.  Any structure type that
:INCLUDEs this type will also contain the same slots; it seems more
reasonable to inherit the parent's print function than to use the
default #S syntax.

Current Practice:

Lucid Common Lisp implements the proposal.  VaxLisp uses #S syntax
unless an explicit :PRINT-FUNCTION is specified.

Cost to implementors:

The changes to non-conforming implementations should be fairly minor
and localized.

Cost to users:

It can't be any worse than the status quo.


An area of ambiguity in the language will be removed.


Perhaps some way of specifying that #S syntax should be used instead of
inheriting the print function of the parent type should be provided for
(such as specifying :PRINT-FUNCTION with no arguments).