[Openmcl-devel] Apparent displaced array type bug
gb at clozure.com
Fri Sep 23 12:17:08 UTC 2005
On Fri, 23 Sep 2005, David Steuber wrote:
> On Sep 23, 2005, at 5:38 AM, Gary Byers wrote:
>> Is the error message below unclear ?
> FSVO clear it probably is. I was confused by the popularity contest pitfall
> of SBCL and CLisp accepting defective code. I was confused because I did not
> know that a displaced array was not a simple array even though the array it
> was displaced to is a simple array.
To make things more confusing: a displaced array -might- be a SIMPLE-ARRAY.
(That's up to the implementation; offhand, I don't know of an implementation
in which that's true.) CL only guarantees that arrays created without
:ADJUSTABLE/:FILL-POINTER/:DISPLACED-TO options are SIMPLE-ARRAYs; it's up
to the implementation whether an array created with one or more of those
options is a SIMPLE-ARRAY or not.
> I learned something new today. Sorry for the bogus bug report. And thanks
> for the very quick response.
> There is on niggling detail left that bothers me. If you refer to the Lisp
> The paste that jdz made from 0.14.3 complains "not of type (simple-array
> (integer 0 128) (* *)). However, the recent cvs version of openmcl that I am
> using complains "not of type (simple-array (mod 129) (* *))".
> What I had not shown in my code fragment was this bit that occurs prior to
> the defclass form:
> (eval-when (:compile-toplevel :load-toplevel :execute)
> (defconstant +max-iterations+ 128))
> So I'm expecting a type (integer 0 128). It doesn't seem obvious to me that
> (mod 129) is the same thing. Is it? If not, then there is still a problem,
> just a different one than I originally reported.
CLHS says (of the MOD compound type specifier):
"This denotes the set of non-negative integers less than n. This is
equivalent to (integer 0 (n)) or to (integer 0 m), where m=n-1."
So yes, (MOD 129) and (INTEGER 0 128) denote exactly the same type.
More information about the Openmcl-devel