[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)
- To: firstname.lastname@example.org
- Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 22 Nov 88 01:51 EST
- Cc: email@example.com
- In-reply-to: <8811220345.AA15102@bhopal>
fyi, KMP does -not- want all arrays to be adjustable, and would prefer
strong checking -- ie, signal of error required when attempting to adjust
an array not declared adjustable.
arguably, this is because KMP has a lot of experience in trying to port
programs where this happened to be a problem and he wants not to have such
problems recur for himself or anyone else. further, KMP does not currently
maintain any programs which would be hurt by this change, so doesn't worry
about the cost of upgrading his code.
in contrast, Symbolics (a company with financial investment in a particular
interpretation of the topic in question) would have to reimplement a bunch
of stuff at considerable expense, and would have to (arguably gratuitously)
break its users' code.
the symbolics view is not that all arrays must be adjustable, by the way.
the symbolics view is that we recognize that in some implementations that
is too expensive even though in ours it is not. as such, from the local
perspective, :adjustable is present so that portable code can specify which
arrays need the greater overhead for the sake of implementations which must
distinguish. adjustable-array-p does not predicate whether the array was
created with :adjustable t, it predicates whether the array is adjustable.
nothing in CLtL specifies that omitting :adjustable or specifying
:adjustable nil means you can't make the array adjustable. as such,
symbolics makes all arrays (except for a -very- few) adjustable but you can
always reliably detect which arrays will be adjustable by calling
adjustable-array-p (if you don't know the array's lineage from context),
and you can always force an array to be adjustable in the first place by
doing :adjustable t. this is a fully consistent point of view that is not
in conflict with CLtL. you may be sad that this loophole is there, but i
assure you that it is no perverse reading of CLtL that led to this
interpretation. it is my belief that if there is confusion it is because
people had differing views on what :adjustable was about when they went into
writing CLtL and the wording was frobbed to make everyone happy without
being explicit about why that particular wording made everyone happy.
it's a case of a situation where person A thinks that everything is either
black or white and person B does not. person A describes a frob as Black.
person B, thinking frobs are really gray says "couldn't we just say it's
not white?" person A, thinking this is the same thing, says "sure." and
voila, person A and person B both have their model of the world supported,
they both agree that frobs are not white, but yet they have -- in some other
sense -- not really agreed.
this is a lot of what the `explicitly vague' issues are about. just to make
the disagreement visible to the reader, so that people from neither camp will
later be surprised by the discrepancies which are bound to arise from
differing world models.
and, getting back to the original subject, other companies have used
extraordinary expense as a show-stopper on other issues. even though i
disagree with moon from an abstract point of view on this, i certainly
think it's both fair and appropriate for him to characterize my favorite
alternative as unreasonably expensive for symbolics, and i hope everyone
will give that position its due consideration.