[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More FORMAT
- To: email@example.com, DFM%JASPER@live-oak.lcs.mit.edu
- Subject: Re: More FORMAT
- From: Guy Steele <gls@Think.COM>
- Date: Fri, 22 May 87 10:46 EDT
- Cc: firstname.lastname@example.org, email@example.com
- In-reply-to: <8705201855.AA02717@vaxa.isi.edu>
Date: Wed, 20 May 87 11:55:34 PDT
From: Richard Berman <firstname.lastname@example.org>
As someone else mentioned, it can be more than useful to know that something
is causing an array to grow. It seems reduntant to me to have an :adjustable
keyword if there are no clear semantics to :adjustable nil, only to
:adjustable T. Especially when :adjustable (non-nil) == :adjustable nil.
Or perhaps we need a :non-adjustable keyword, just to keep our semantics
consistent, where :non-adjustable T means "definitely" non-adjustable, and
:non-adjustable nil means "maybe non-adjustable"?
It is not redundant. It is, however, in some sense merely an
efficiency hint. :ADJUSTABLE NIL is a promise on the part of the
programmer never to try to adjust the array. The value of this
promise is that the implementation may then be able to create
an array that uses less time or space.