[Re: early error detection]

[goldman@VAXA.ISI.EDU]

        ...  But the point was that the
        complaint had no basis given that the documentation states clearly 
        that the :type option is for controlling the implementation of the 
        data structure rather than for type checking. 

Gee, I apologize profusely for sending out "complaints" that have "no basis".
Maybe you can enlighten me as to the documentation I SHOULD be reading
(which is so clear as to the purpose of declarations) -- apparently
it is not the documentation on page 310 of Steele, nor that on page 153.

I must also point out that my "complaint" was NOT about the fact that
symbolics' compiler/interpreter chooses to ignore a :type specification
for a defstruct slot, although that was indeed one of the EXAMPLES I used
in my message.  My complaint was a about a patently false claim by a 
submitted by a symbolics employee -- namely, that symbolics "architecture"
detects type errors at the earliest possible moment.  It does not detect
them at the earliest possible moment, and it does not necessarily detect them
at all.  It detects a subset of all type errors -- namely, those involving
a selected set of predefined types(e.g., number) used as operands to a
selected set of predefined operations (e.g., +).

I am still at a loss to understand how the following two reactions to my
initial message can be self-consistent:
a) doing more type checking than is done by the symbolics archtiecture
   would be TOO EXPENSIVE
b) if I want more type checking, I should code in terms of FLAVORS even where
   structures would be functionally adequate.
I find it very hard to believe that adding software type checking for
declarations involving structure types, as a way of catching more, though
certainly not all, type errors, cannot be made considerable more efficient
than (b).

Saying that adding software type checking is TOO EXPENSIVE is a non-response.

Here is what I would consider some possible satisfactory responses:

1) We don't have any idea how to compile code containing declarations
   into instructions that perform type checking and signal errors.

2) We don't think anyone would want more type errors to be detected, or to have
   type errors detected eearlier.

3) We don't have the resources to investigate the issue at this time.
    --i.e., it is currently TOO EXPENSIVE to investigate.

4) We have thought about using common lisp type declarations to detect
   more type errors, and we estimate these costs:

   to detect the following type errors not currently detected
  (e.g., enforce type declarations on the input parameters of functions
     at function call time, but not assignments to those parameters within
     the function, for all predefined atomic type specifiers and for types
     introduced by defstruct and defflavor)
   would increase code size by xx instructions per enforced declaration,
   and would increase function entry time by yyy% for, say, a function
     of 3 parameters all of which had an enforced type declaration,
   and it would take us mmm man-months to provide selective enforcement
     of these declarations based on common lisp's SAFETY/SPEED optimization
     declarations.
   In light of these cost esitmates, we do not believe our user community would
     derive sufficient benefit from the facility to make it worth implementing.

Anyone from symbolics care to choose one of these answers, or try something
else more meaningful than "its too expensive to detect any more type errors
or detect them sooner."