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

Re: type slot option



     
     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?
     -------

I think this issue is too big to be decided in this group. I wouldn't
take decision before asking the whole X3J13. In case it produces an
endless and intractable discussion, I would be in favor of turning off
this option until a concensus emerges.

Patrick.