[Openmcl-devel] Apparent displaced array type bug

[Gary Byers]

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 
> Paste:
>
> http://paste.lisp.org/display/11910#2
>
> 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.