Issue DEFSTRUCT-DEFAULT-VALUE-EVALUATION Writeup

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.