type slot option

[Gregor.pa@Xerox.COM]

One of the comments we received attacked several problems with the :type
slot option.  The complaint, which came from Dan Pierson, sees to be
that because the :type option is not enforced by automatically defined
accessors or slot-value, you can't count on it to protect a slot from
having the wrong type of value stored in it.  It seems he is thinking of
the type option as a `semantic' feature, rather than an optional
compiler declaration.

Here are his comments:

    Date: Wed, 13 Apr 88 13:19 PDT
    From: Dan L. Pierson <pierson%mist@multimax.ARPA>
    
      Comments on Chapters 1 and 2 of the CLOS Spec (Edition of 2/8/88)

    Page 1-13, Paragraph 4
    	    This paragraph appears self-contradictory.  I think that
	    it means that portable code cannot depend on slot types
	    since:
	    	(1) Some implementations may not provide type errors
		    (therefore reducing the value of slot types for
		     debugging), and
		(2) Calls from outside the package may store incorrect
		    types (so even if your portable code is self-consistent
		    you could wind up with undetected type errors).

    Let's say you're implementing a window system which has slots
    WINDOW-WIDTH and WINDOW-HEIGHT.  You define these slots to be of type
    integer *and* ensure that your code never puts a non-integer in them.
    You still have to explicitly check the type of the slot value every
    time any code that you didn't write could have run because a user
    program could have put a non-integer in the slot without getting an
    error in some implementations.

Moon said:

Common Lisp defines errors with respect to a single program.  Common
Lisp does not address the issue of how one program can protect itself
against language violations committed by another program running in the
same Lisp.  I don't think this problem is specific to CLOS in any way.
I don't think it's CLOS's business to do anything about it.  Of course
I'd like to see Common Lisp fixed to eliminate this problem, for example
by completely eliminating the concept of type declaration.  However in
the real world that is not going to happen; historically programmers
have been eager to accept incorrect code for the sake of efficiency.


Gregor said:

This is a problem.  The reason we are losing is that we are thinking of
this :type slot option as a compiler feature whereas some user might
think of it as a real semantic feature.  There are several ways out:

  - drop the :type slot option entirely
  - say that writer methods will check the type, but setf of
    slot-value might not
  - say that everything which write into the slot will check
    the type
  - say that everything which write into the slot should check
    the type
  - leave things the way they are, but make it clear that it
    is the job of the user code to enforce the type option.



Moon said:

You're right that :TYPE is a compiler optimization, not a semantic
feature.  It's like the TYPE declaration in that respect.  If slot
options had been defined in a syntactically consistent way (i.e.
enclosed in parentheses like class options) then the syntax of this
slot option could have been based on the syntax of DECLARE and just
possibly people would be less confused about what it means.  I'm not
seriously proposing that; I'd rather eliminate the option, if we're
going to make such a large change.


What should we do about this?
-------