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

[Barry Margolin <barmar@Think.COM>]

    Date: Fri, 17 Mar 89 16:08:50 PST
    From: Jon L White <jonl@lucid.com>

    re: I find (1) distasteful, because non-adjustable arrays and the
	SIMPLE-ARRAY type exist solely for the benefit of implementations that
	need them, and this would require support of these concepts in
	implementations that don't derive any benefit from them.  

    Barry, SIMPLE-ARRAY is certainly not the only concept in CLtL that exists
    "solely for the benefit of implementations that [can really use it]".  I
    know that numerous array capabilities are present but not very useful
    in Lucid Common Lisp primarily for compatiblity with Lisp Machine stuff.

    That's the price to pay for portability.  It just may be that we will have 
    to confess that we didn't succeed at portability in some areas of CL.

    -- JonL --

The general rule has been that implementations that don't need (or don't
provide) these types of optimizations can safely ignore the language
features that support them.  Some implementations can optimize array
access by knowing that the array can't be adjusted; other
implementations should not be required to remember this information if
they don't need it.  Quoting from CLtL: "features that are useful only
on certain 'ordinary' or 'commercial' processors are avoided or made
optional."

Any feature of the language that provides access to facets of the
implementation allows somewhat non-portable code, meaning that it is
possible to write conforming code that produces different results in
different implementations.  The simple program (PROGN
MOST-POSITIVE-FIXNUM) is conforming but produces many different results,
although the program (TYPEP MOST-POSITIVE-FIXNUM 'FIXNUM) is guaranteed
to return T in all conforming implementations.  To paraphrase Moon, it
would be wonderful if all conforming programs were portable, but that's
unrealistic (it would be like expecting the grammar of a language to
only permit sensible sentences to be formed -- I suspect Godel's
Incompleteness Theorem comes into play here, pointing out that if the
grammar allows you to say everything you'd want to say, it must also
include some nonsense).  The best I think we can do is provide enough
tools in the language to allow programs to detect implementation
differences and deal with them.

One thing that would help me is if you would post an example of code
that you feel is affected by this issue.  I think you described such
things to me in words at the last meeting, but I (like GLS) am having a
hard time figuring out precisely what the problem is (I had the same
difficulty with the FIXNUM stuff that started the moby flame session in
the car on the way to the Japanese restaurant).

                                                barmar