Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES

[Dan L. Pierson <pierson@mist.encore.com>]

        Sorry, but that's exactly the opposite of what I meant.  If I declare
        an array, FOO, to be (SIGNED-BYTE 5), within the scope of that
        definition I'm saying that expect references to that array to be
        equivalent to:
            (THE (SIGNED-BYTE 5) (AREF FOO X))
        No matter what the array was upgraded to.  
    
    Yea, that's what I thought you meant, and that's what I think is
    inconsistent with the "unification" in issue ARRAY-ELEMENT-TYPE-SEMANTICS.
    
It seems that we disagree here.  I'll remove your endorsement from the
next version of the proposal.

    re: As I've said before, I support a strict type checking mode for all
        Common Lisp compilers.  However I now suspect that it's too late (and
        maybe too experimental) to get in this version of the standard.  I
        said I'd write up a proposal for it at the cleanup meeting last
        October, but was later talked out of doing so.
    
    Why?  [i.e., Why did you get "talked out of doing so"?]  I remember 
    discussing this with you at length during the Palo Alto meeting in
    March 1988 and likeing it very much.  However -- I hasten to point
    out -- it would help not to confuse this issue with the very limited
    scope of DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES, which has it's own
    peculiar problems related to "upgrading".
    
Well, it was a combination of factors: the issue looked to be
extremely controversial; several well respected people were arguing
against much milder proposals on the grounds that no one had
implemented them (FUNCTION-COMPOSITION comes to mind); and Larry made
a strong pitch that time was running out and we should concentrate our
efforts on the important issues that still might be resolved in time.

I clearly don't have time to do a full writeup by Hawaii, but am still
willing to consider doing one later; I've also considered a Lisp
Pointers article as an alternative or addition.  It seems that a very
relevant question is whether any vendors would consider making such a
feature part of their product if it wasn't required.  If the answer to
that is no, then I would have to reluctantly admit that the
standardization case is -very- weak.  

Right now, I'm more likely to devote time to a foreign function
interface standard, since almost everyone implements the feature and
many of the differences are clearly unnecessary, if not plain
gratuitous.  The same arguments might apply to multiprocessing ala
stack groups (though emphatically not to parallel lisp).

Just to remove any doubt, I personally think that such a "string
typing" feature is very, very valuable and have felt and argued that
way since the early VAX Lisp days.  For one thing, the lack of this
feature makes it extremely difficult to move a non-trivial application
 from low SPEED, high SAFETY to the reverse.  You currently have to go
straight from generic operations that "always" work to no-holds-barred
inline code where errors can do anything; a mode that checked your
declarations and signalled precise errors would make debugging and QA
of such an application vastly easier.  If we want people to produce
serious applications and products with Common Lisp, we have to give
them the tools to produce efficient and safe code without sacrificing
the traditional development advantages of Lisp.  This feature helps do
exactly that.