Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Disclaimer: The contents of this note are my personal opinion and not
	    necessarily the opinion of Symbolics.

Summary: I'm quite upset by this message of JonL's, not because of its
	 technical position, but because of the lack of personal respect
	 JonL has shown for my technical position. This message has some
	 technical content, and therefore I want it in the CL-Cleanup
	 archives, but its primary content is political, emotional, and
	 personal. As such, recipients other than JonL shouldn't treat it
	 as high priority reading.

-----
    Date: Tue, 6 Dec 88 22:40:23 PST
    From: Jon L White <jonl@lucid.com>

    ... 
    This may be the Symbolics 3600 status quo (and TI Explorer); but no other
    implementation I'm aware of takes this variant view of CLtL.  Considering
    the strong, though not unanimous,  opposition  to making all arrays 
    adjustable, I don't see how you can expect to resolve the debate simply
    making such a statement.

Status quo has, to the best of my knowledge, always been taken in our
discussions to mean "what is implemented", not "what is understood by an
elite group of people who designed CLtL in the first place". We have usually
reserved the phrase "what was intended" to refer to what people might have
had in mind, and we might debate what was intended, but as far as I'm
concerned there is never any debate on the status quo.

I discount from the status quo only obvious violations (eg, an implementation
fails to support bignums) where no defensible reading of the manual will cover.
I count for the status quo -any- implementation for which there is a passage
in CLtL which the implementors claim to have faithfully interpreted and which
they have made a financial investment in.

I did not question the validity of someone's claim that Choral had implemented
NCONC as APPEND. They claim this was a mere bug, but if they hadn't, I would
have been willing to accept it as the "status quo" (even if not "what was
intended") because they can probably find text to back it up.

If you take a different view of the status quo, you should go back to Mathis or
that nice lady who on the first day of X3J13 gave us a lesson on the legalities
of X3J13 and the dangers of claiming to be able to "interpret" CLtL. You'd
better be -very- careful not to make any public statements of the form
"Implementation X is not conforming because of ..." unless you're prepared to
cite written text (not popular myth) to back yourself up or you may find yourself
in court backing up such slanderous claims. Such, at least, was their contention,
and I'm inclined to believe they were right to warn us thus.

It is not the business of this committee to retroactively invalidate good faith
implementations of CLtL. If we want to make tougher standards, we can do so only
by making a new standard which is more rigorously defined.

    Why not just admit that the intent of simple arrays was to accommodate 
    the needs of "stock" hardware implementations?

I admitted this already.

    Thus remembered, no one could mistake the intent for SIMPLE-ARRAYs -- that
    they be non-adjustable. 

Not so. Our collective recollection is that you were -permitted- (not -required-)
to make them be non-adjustable.

    Indeed, why create such an arbitrary type subset if it were only of 
    theoretical interest?  [Remember also the "RPG Memorial Array" proposal.]  

It isn't only of theoretical interest. It's clearly a bug that ADJUSTABLE-ARRAY-P
doesn't predicate whether ADJUST-ARRAY will work. That should just be fixed.

It's not clear that it's a bug that the effect of doing :ADJUSTABLE NIL
was not specified. There are plenty of useful applications that derive
 from the interpretation we support.

    Then this whole disingenuous 

Excuse me, but this kind of thing really pisses me off. This adjective has no
place in any discussion of this sort and if I see it again I will disinvolve
myself with this and perhaps any further discussion.

We could not be more up front and sincere: We have said some people here believe
the wording is as it is for a reason. The reason, while not popular -- I don't
even like it personally -- is completely defensible from a technical standpoint
and not subject to any kind of common sense arguments that there was "only one
possible interpretation". There may have been only one "obvious interpretation"
but on inspection you should be willing (as am I) to agree, at least reluctantly,
that this is a valid point of view -- if for no other reason because people
whom you hopefully respect have asserted that it is a valid point of view.

In general, my rule of thumb for what is ambiguous is anything for which all
parties cannot be convinced, through discussion, is not ambiguous. This is,
if one party thinks something is ambiguous and one party thinks it is not, then
by (my) definition, it is ambiguous. The only exceptions are extreme cases where
where the individual claiming ambiguity can be demonstrated to have insufficient
command of the issue (eg, hairy floating point stuff) or insufficient command
of the English language; I assert that on this issue, I have neither of these
deficiencies, and that my claim of ambiguity is generous.

    re-reading of the history of adjustable 
    arrays and "loopholes" in CLtL could be dropped; and Symbolics could 
    simply say something like:
	"Symbolics extends Common Lisp ARRAY functionality in an improved,
	 but technically incompatible, way." 

It is your burden to demonstrate that it is incompatible. I have cited
specific passages with which you might quibble about "original intent" but
you cannot quibble about "technically compatible". In point of fact, we are
within the letter of the stated rules, and we have cited reasons 

I've said over and over that I don't happen to personally like the Symbolics 
[Genera] interpretation (Cloe's interpretation is different :-), but I think
they/we are within their/our rights to claim it.

    That simple, frank statement would make everybody much more comfortable
    (especially 3600 user's who wonder why their code doesn't port), and 
    would finally close the debate so that we don't have to waste yet more 
    and more time on it.

Don't hold your breath. It's just not as simple as that. There are really major 
issues of compatibility and QA that we have to deal with, and the expense for
us would probably not be small.

Besides, the Cloe development environment (which is what I and many others
here recommend for people porting code out to other environments) does offer
the interpretation you suggest.

    [Yes, I'm aware that Symbolics would have to face 
    persistent demands from some of their users to "come into compliance"; 
    but it's much more likely that you can make satisfactory explanations to 
    these customers than that you can convince the "stock hardware" types to 
    swallow universal adjustability.]

I don't see why either of these extremes is necessary. I'm not advocating
that stock hardware swallow universal adjustability and I'm asking them not
to force this change on us.

Virtually every other vendor has at one time or another indicated that some
proposed change would be prohibitively expensive. We have generally treated
such claims with respect. Rarely has anyone had the gall to suggest that they
should just bite the bullet and accept an enormous incompatible change or
"just declare themselves to be incompatible" (a dangerous trend). In general,
such proposals have stopped dead in their tracks until/unless someone could
propose a serious way around the difficulty -- and "just declare yourself to
be incompatible" has never been an avenue open to us before. I am awestruck
that you could suggest this.

If you want to disagree with our proposal on technical grounds, that's fine.
But keep in mind that compatibility with existing code, transition cost, etc.
are legitimate concerns applied in every other proposal writeup and we're
fully entitled to assert that this is a proposal of major cost to us. 

I think, too, we're within our rights to ask for a little respect from the
other members of CL-Cleanup when we assert such a position.

I personally would like to see the tighter definition you'd like to see,
but given the potential expenses involved, I see nothing disingenuous
about my having described the status quo as I did, and nothing
unreasonable about my having suggested that this is our only viable
alternative.