Re: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)

[masinter.pa@Xerox.COM]

The minutes from the June meeting say "The discussion of
DEFSTRUCT-DEFAULT-VALUE-EVALUATION led to  no resolution of opinion so it was
decided not to bring the proposal to a motion."

I cannot recall what, if any, controversy was associated with this proposal.
JonL had some additional comments, but I didn't see that they would require any
changes to this issue per se (correct me if I am wrong.)

To refresh your memory:

!
Issue:          DEFSTRUCT-DEFAULT-VALUE-EVALUATION
References:     CLtL p.308-10 & 86-003 p.4
Category:       CLARIFICATION
Edit history:   Revision 1 by Skona Brittain 05/13/88


Problem Description:

There is some confusion over whether default initialization
forms for defstruct slots get evaluated, when they are not needed
because a keyword argument was supplied to the constructor function.
As a consequence of this confusion, there is confusion over whether
there can be a type-mismatch error between the specified type of the slot
and the type of the default value.

On page 308, it says "The default-init is a form that is evaluated 
each time a structure is to be constructed; the value is used as the 
initial value of the slot.  If no default-init is specified, then the
initial contents of the slot are undefined and implementation-dependent."

On the next page, however, it says that the default-init is evaluated if
the keyword argument is not supplied and the converse, although not stated,
is intended and informally implied.


Proposal (DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED):

Clarify that the converse is true. i.e that the default-init is not evaluated 
if the keyword argument is supplied.

In the quote from page 308, delete the second sentence and replace 
"a structure is to be constructed; the value is" by "its value is to be".

To section 19.3, add a clarification,
such as the following from Guy's issues file:
       "The default value in a defstruct slot is not evaluated 
        unless it is needed in the creation of a particular structure
        instance.  If it is never needed, there can be no type-mismatch
        error, even if the type of the slot is specified, and no warning
        should be issued."


Test Case:

In the following sequence, only the last call is an error.

        (defstruct person (name 007 :type string)) 
        (make-person :name "James")
        (make-person)


Rationale:

It is inefficient, and inconsistent with the rest of the language, for the 
default initialization form to be evaluated when it is not needed.
Consequently, when it's not needed, such type-mismatch errors should not be 
detectable in general.

Any existing confusion should be clarified by this proposal.


Current Practice:

KCL does not evaluate the default initialization form unless it is needed;
even when it is needed, the type checking is not done at all.


Cost to Implementors:

If there are any implementations that currently behave differently from
the proposed way, then they need some slight modification.  


Cost to Users:

None.


Benefits:

Clarity and portability.  In particular, clarifying that the unaesthetic 
situation mentioned in the next section is allowed should be reassuring.


Aesthetics:

It appears slightly unaesthetic to have a default value that violates a 
type specification.  


Discussion: 

Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.

!
Additional notes:

Several members of the cleanup committee endorsed this proposal.

JonL added:

You can add to the "Current Practice:" section:

    LUCID does not evaluate the default initialization form unless it is 
    needed; even when it is needed, the type checking is not done at all.
    However, at structure definition time, if an initial value form is
    constanp and doesn't satisfy the :type specification, a warning message
    is printed.

Oddly enough, Lucid's interpreter ensures that SETF's of slots obey the
:type specifier, even though init-forms aren't checked.  Furthermore, in 
safety levels 2 or higher, the compiled code will do minimal "memory-
integrity" type checking for SETF's (which is what I suspect the various 
special-purpose microcoded machines do); however except for low-level numeric
types, this is rarely equivalent to what a full type check would do.

I have long suggested that there should be at least one mode of operation 
such that all :type information is checked when setting values into structure
slots (setf as well as initialization).  Some have suggested that this mode 
could be "when running interpretively, or when when compiled with the highest
degree of SAFETY and lower degrees of SPEED."  However, since the wording of 
CLtL p310 suggests that the :type slot options is merely a DECLARE, and since
some vendors effectively ignore any and all declarations [except for SPECIAL],
then this suggestion hasn't reached proposal stage yet.